Web Application Penetration Testing, Explained

A web application penetration test is a person attempting to misuse your application on purpose, within an agreed boundary and a fixed window, and writing down what worked.

That sounds obvious, but it is the whole distinction. An automated scanner sends a large number of known-bad inputs at your application and reports which ones produced a suspicious response. A penetration tester builds a model of what your application is for — who the users are, what they own, what they are supposed to be prevented from doing — and then attacks that model. The second approach finds a category of problem the first cannot see at all.

This describes what actually happens during one, written for the person who will be handing over the credentials rather than the person approving the invoice.

The three perspectives, and why one of them matters most

Almost every scoping conversation turns on which of these you are buying.

Unauthenticated

The tester has no account and works from the outside, as an anonymous internet user would. This covers the login and registration flows, password reset, anything reachable before sign-in, and the perimeter of the application itself.

It is the cheapest option and the least informative one. Most real applications keep almost nothing of value in front of the login, so an unauthenticated test frequently returns a thin report — which is sometimes mistaken for good news.

Authenticated, single role

The tester is given a normal user account and works as that user would. This reaches the bulk of the application, and it is where most findings come from.

Authenticated, multiple roles

The tester is given at least two accounts — often a standard user and an administrator, or two users belonging to different customers — and the test includes whether the boundary between them holds.

This is the perspective worth paying for. Broken access control is consistently the most common serious finding in web applications, and it is structurally invisible to a single-account test. If a tester only ever holds one set of credentials, there is no way to establish whether user A can reach user B's data, because there is no user B.

The cost difference between one account and three is small. The difference in what the test can conclude is not.

What actually gets tested

The categories below are roughly the order a tester works through them, and roughly the order of how much trouble each tends to cause.

Access control

Whether the application enforces its own rules about who may see and do what. Two shapes:

• Horizontal — can one user reach another user's records at the same privilege level? The classic form is an identifier in a URL or request body that the server trusts without checking ownership. Change /api/invoices/1042 to /api/invoices/1041 and see what comes back.
• Vertical — can a standard user reach administrative functions? Often the interface simply hides the button while the endpoint behind it remains open to anyone who knows the path.

This is the category that most rewards having several accounts, and the one scanners cannot meaningfully attempt, because a scanner has no idea which records are supposed to belong to whom.

Authentication and session handling

Whether the login mechanism can be bypassed, worn down, or side-stepped. In practice this covers credential stuffing resistance and rate limiting, the password reset flow — historically one of the weakest parts of most applications — multi-factor implementation, and what happens to a session at the moments that matter: logout, password change, role change, and concurrent sign-in.

Where JSON Web Tokens are used, the tester checks whether the signature is actually verified, whether the algorithm can be changed by the client, and whether claims inside the token are trusted without a server-side check.

Injection

Whether input crosses from data into instruction — SQL, operating system commands, template expressions, LDAP queries, and anything else the application hands to an interpreter.

Modern frameworks have made classic SQL injection much less common than it was. It has not disappeared, and it tends to survive in the places the framework does not reach: hand-written reporting queries, search filters, bulk import routines, and legacy endpoints nobody has touched in years.

Business logic

Whether the application can be made to do something legitimate in an illegitimate order, quantity, or sequence. Applying a discount code more times than intended. Skipping a step in a multi-stage process by requesting the final step directly. Submitting a negative quantity. Completing a purchase while the payment is still pending, by exploiting the gap between two requests.

Nothing automated finds these. They are not malformed input — every request involved is well-formed and individually valid. They are only visible to someone who understands what the workflow is supposed to achieve, and they are frequently the findings with the most direct financial consequence.

Server-side request forgery and file handling

Whether the application can be persuaded to fetch a URL of the attacker's choosing, or to accept, store and later serve a file it should have rejected. Anywhere the application takes a URL, imports from a remote source, generates a document from a template, or accepts an upload, this gets attention.

Client-side

Cross-site scripting in its stored, reflected and DOM-based forms; cross-site request forgery on state-changing actions; clickjacking; and the security-related response headers, which are quick to check and quick to fix.

What the tester needs from you

The most common cause of a disappointing test is not the tester. It is the first three days being spent waiting for access.

• Working credentials for every role in scope, tested by you before handover, and not subject to a lockout that triggers on the second failed attempt.
• An environment that resembles production. An empty staging instance with three test records cannot exhibit most access-control flaws, because there is nothing to reach across to.
• Allowlisting. If a web application firewall or rate limiter sits in front, decide deliberately whether the tester works through it or around it. Both are defensible. Discovering on day four that the firewall has been silently dropping requests is not.
• A named technical contact who can answer a question the same day.
• Any documentation that exists — API specifications, a description of the role model, notes on which parts are new.

The preparation checklist covers this in more detail, including the parts that need to happen weeks ahead.

How long it takes

Duration follows the size of the attack surface, not the size of the codebase. A tester counts distinct functions, roles, and entry points.

A small application with one role and a handful of screens is a few days. A substantial application with several roles, an administrative interface, a payment path and an API behind it is commonly two to three weeks of testing, plus reporting. Anyone quoting a fixed duration before seeing the application is quoting a price, not an estimate. What drives that number is covered in what moves the price of a penetration test.

What it does not cover

Worth being explicit, because the gap is where unpleasant surprises live.

A web application test looks at the application. It does not review source code unless a code review is separately scoped — a tester works from the outside in, and some flaws are far easier to see from the inside. It does not test the underlying infrastructure beyond what the application exposes. It does not assess your people, which is a social engineering exercise. And it describes a single moment: the result is valid for the version tested, on the day it was tested.

That last point is the argument for retesting after fixes, and for testing again after significant change — not as an upsell, but because a report about a version you no longer run is a historical document.

What comes back

A findings report, with each issue carrying reproduction steps, evidence, a severity rating and remediation guidance. The section-by-section walkthrough is in what is actually inside a VAPT report, along with the specific thing to check in each part.

The one check worth repeating here: read the reproduction steps on the most serious finding. If you cannot follow them yourself and observe the same result, neither can your developers, and neither can anyone confirming later that it was fixed.