Web and application penetration testing: what gets tested and what you receive

Web and application penetration testing is a human-led security assessment that looks for exploitable weaknesses in your web application, mobile app, or API before a real attacker finds them. The result is not a list of flags from an automated scan but direct evidence: the exact path a tester took, what they were able to access, and what that access would mean for your business. This page explains the scope, methods, and report contents for this type of engagement. For timeline planning, see how long a penetration test takes.

Testing scope: web, mobile, and API

The three main scope categories differ in where a tester enters the system and how they approach it.

The boundary between these categories blurs in practice. A well-built mobile and web application share the same backend API, so a weakness in the API layer affects both interfaces. This is one reason a combined scope often uncovers more meaningful findings than testing each layer separately.

Methods: black-box, grey-box, and white-box

The choice of method determines where the tester starts and how deep the assessment can reach within the time available.

Black-box testing simulates an external attacker who knows nothing about your system. The tester starts from zero: gathering public information, exploring visible interfaces, and trying to gain a foothold without any inside access. This is the most realistic approach for measuring what an attacker with no insider connection could accomplish.

Grey-box testing gives the tester some initial context, usually an authenticated user account, API documentation, or basic architecture information. With that background, testing time can focus on deeper logic: can a regular user access another user's data, can privileges be escalated, or can a business flow be manipulated for unintended gain? Grey-box produces deeper findings per hour of testing than black-box does, and it is the most common choice for regular scheduled assessments.

White-box testing includes source code, configuration, and full access to the architecture. The tester can trace logic that is completely invisible from the outside, including race conditions, weaknesses in cryptographic implementations, and business logic that can be abused from within the system. This is the right choice for high-risk applications or before launching a new product.

The right method depends on the question you need answered: how far could an external attacker get, or how deep do the hidden flaws go inside the application.

How testing is conducted

All scope types follow the same sequence. The depth of each phase depends on the method chosen and the scope agreed at the start.

Scoping defines the targets, method, rules of engagement, and stop conditions. Reconnaissance gathers information about the attack surface: active subdomains, exposed endpoints, technology versions, and third-party components. Enumeration maps finer detail across each target. Exploitation is where the tester attempts to leverage discovered weaknesses to prove their impact. Impact validation measures how far access can reach and what data is reachable. The report turns all findings into an actionable document, and the retest confirms that the fixes applied are effective.

The tester keeps a live communication channel open throughout the engagement. If something looks fragile or risks disrupting a live service, testing can be paused before any unintended effect reaches the production environment.

The attack surface that gets tested

The diagram below shows the layers reached in a web or mobile application assessment. Each layer carries different attack vectors, and a thorough test touches all four.

An assessment that only touches the interface layer misses most of the real vulnerabilities. Authentication weaknesses, flawed business logic, and over-exposed APIs are almost always found at deeper layers that are invisible from the outside.

Vulnerabilities found most often

Across many application assessments, several patterns repeat consistently regardless of the size or technology stack of the application.

The severity of each finding depends on the specific application context. Findings rated critical or high always involve access to data that should be protected, not just the ability to disrupt a service.

What the report contains

A good penetration testing report gives the technical team enough detail to fix every finding, and gives management a view of business risk they can understand without a security background.

The report is issued in both Indonesian and English. The retest covers only the findings you have fixed and is appended to the original report as an addendum, so an auditor or partner can see progress without requesting a separate document.

Penetration testing and Indonesian regulatory requirements

Application security testing is not only a best practice; in several Indonesian regulatory contexts, it is a requirement.

Commercial banks under SEOJK 29/2022 are required to run scenario-based testing at least once a year, and the results reach OJK within ten working days of the test being completed. That testing may be run by the bank's own team or by a third party whose competence the bank verifies (SEOJK 29 romawi VII.5), while the frequency of vulnerability-analysis testing is set by the bank's own evaluation. Payment system operators under PBI 2/2024 are required to maintain and test their security detection systems (Pasal 29 ayat (1)). For organizations pursuing ISO 27001 certification, recent technical testing evidence is routinely requested by auditors.

The specific testing obligations for banks and their basis in SEOJK 29/2022 are detailed in our guide to pentest requirements for Indonesian banks.