Web Application Pentesting

Web application testing is where most people enter offensive security, and where the gap between tooling and skill is widest. A scanner finds reflected XSS. It does not find that user 1042 can read user 1043’s invoices by changing a number, which is usually the finding that matters.

Everything here assumes authorized testing with defined scope and written rules of engagement.

Methodology, and why it beats intuition

OWASP WSTG and PTES exist because unstructured testing has a characteristic failure: you test what you’re good at, run out of ideas, and report. Coverage is unmeasurable, and the gaps correlate with the tester rather than the application.

A methodology gives you a completion criterion — every category considered against every identified surface, with explicit notes where something was out of scope or untestable. In practice the sequence is: map the application, enumerate roles and trust boundaries, then test each category against each boundary.

The mapping phase is where inexperienced testers under-invest and where the good findings originate. You cannot test authorization for a role you never discovered.

Recon and mapping

The goal is a model of the application: its surfaces, its roles, and where trust changes hands.

Worth building explicitly:

• Endpoint inventory, including those not linked from the UI — JavaScript bundles routinely reference API routes the interface never calls.
• Role matrix. Every role, every function, and which combinations you have credentials for. This is the artefact that makes authorization testing systematic.
• Trust boundaries. Where does data cross from user-controlled to trusted? Every crossing is a candidate.
• Technology fingerprint. Framework and version shape which classes are plausible.

Old API versions left routed are a recurring finding: /api/v1/ still live and unpatched after everything moved to /api/v2/.

Authentication and session testing

Standard ground, with the parts that get missed:

• Registration and recovery. Password reset is frequently the weakest authentication path — token entropy, expiry, single use, and whether the token binds to the account.
• MFA implementation. Enforced on every path, or only the primary login? Legacy endpoints and API tokens often bypass it entirely.
• Session lifecycle. Rotation on privilege change, actual server-side invalidation on logout, concurrent session handling, and idle timeout.
• Token handling. For JWTs: is the signature verified, is alg pinned, does the application accept tokens it issued for a different audience.

Authorization — the highest-yield category

Broken authorization is consistently the most impactful class and the least amenable to automation, because a scanner cannot know that document 1042 belongs to a different tenant.

Two dimensions:

Vertical — can a lower-privileged user perform higher-privileged actions? Test by capturing an admin request and replaying it with a standard user’s session.

Horizontal — can a user reach another user’s data at the same privilege level? This is IDOR/BOLA, and it is everywhere. Identify every object reference and try substituting another user’s identifier.

The systematic approach is the role matrix: for each function, attempt it as each role, and record the result. Tedious, and it finds what nothing else does.

The frequent underlying cause is authorization enforced in the UI rather than the API — the button is hidden, the endpoint is not. That maps directly to AppSec’s broken object-level authorization.

Injection and business logic

Injection families — SQL, command, template, LDAP, NoSQL — are well covered by tooling for the obvious cases, and the value you add is in the non-obvious: second-order injection where input is stored then used unsafely later, and injection into contexts the developer didn’t consider a parser.

Business logic is where scanners stop entirely, because the flaws are only visible if you understand what the application is for:

• Negative quantities, or quantities that overflow
• Applying the same discount code repeatedly, or racing two redemptions
• Skipping a step in a multi-step workflow by requesting the final endpoint directly
• Manipulating price or state in a client-side value the server trusts
• Race conditions where a check and its use are not atomic — parallel requests against balance checks and one-time actions

These are usually the highest-severity findings and always require thinking about intent rather than syntax.

Client-side and chains

XSS, CSRF, CORS misconfiguration and prototype pollution matter most in what they chain into. Stored XSS in an admin view is account takeover of an administrator, not a popup.

The chains worth constructing deliberately:

• File upload → path traversal or content-type confusion → code execution
• SSRF → cloud metadata endpoint → credentials — the highest-impact chain in cloud-hosted applications, and the bridge into cloud pentesting
• XXE → file read → credentials → lateral movement

Report the chain, not its links. “SSRF in the avatar fetcher” is a medium; “SSRF reaching the metadata service, yielding role credentials with S3 read on the customer bucket” is a critical, and it is the same bug.

Where this connects

Every finding here maps to a control that was missing in AppSec — the same catalog from the other side. Chains that reach the metadata service continue in cloud pentesting. The tooling is in tools and commands, and whether any of it gets fixed depends on the writeup.