Web Application Penetration Testing Methodology: What a Real Assessment Covers Beyond Automated Scanning

The Scanner Gap: What Automation Misses

Automated vulnerability scanners are essential tools in a security program. They provide broad, fast coverage for known vulnerability patterns — and every penetration tester uses them as a starting point. But treating a scanner report as a penetration test is like treating a spell checker as a copy editor. The scanner checks syntax. The pentester understands meaning.

In our web application assessments at Lorikeet Security, we consistently find that 60-80% of critical and high-severity findings come from manual testing, not automated scanning. The scanner identifies that an API endpoint accepts user input. The pentester discovers that the same endpoint allows any authenticated user to access any other user's data by changing an ID parameter — a Broken Object Level Authorization (BOLA) vulnerability that the scanner has no way to detect because it requires understanding the application's authorization model.

The categories that scanners fundamentally cannot test include: business logic flaws (the application does exactly what it was coded to do, but the logic is exploitable), authorization bypass (requires understanding which users should access which resources), chained vulnerabilities (combining two low-severity findings into a critical-impact attack), race conditions (timing-dependent behaviors that require concurrent requests), and multi-step workflow abuse (exploiting assumptions in sequential processes).

Phase 1: Reconnaissance and Mapping

Before testing begins, the pentester maps the application's entire attack surface. This goes far beyond spidering URLs — it includes identifying every API endpoint (documented and undocumented), understanding user roles and permission levels, cataloging input vectors (forms, headers, cookies, WebSocket messages, file uploads), and documenting the technology stack.

Undocumented endpoints are a consistent finding. Applications frequently expose development, staging, or administrative endpoints in production — /api/v1/admin/users, /debug/config, /graphql with introspection enabled, or legacy API versions that bypass newer security controls. Directory brute-forcing, JavaScript analysis (reviewing bundled source for API calls), and API documentation discovery (Swagger/OpenAPI files left accessible) reveal the endpoints that the development team forgot they deployed.

Technology fingerprinting identifies frameworks, libraries, and infrastructure: response headers revealing server versions, cookie names indicating session management frameworks, error messages disclosing stack traces, and JavaScript libraries with known vulnerabilities. Each technology has specific attack vectors the pentester will prioritize.

Phase 2: Authentication Testing

Authentication is the front door. If it fails, nothing behind it matters. Manual testing covers:

• Credential policies: Password complexity enforcement, account lockout behavior, enumeration via login error messages ("Invalid password" vs "Invalid username" reveals which usernames exist)
• Session management: Token entropy, session fixation, concurrent session handling, session invalidation on logout and password change, cookie flags (httpOnly, Secure, SameSite)
• Multi-factor authentication: Bypass via direct API access, MFA code brute-force (lack of rate limiting), MFA fatigue testing, backup code generation weaknesses
• Password reset: Token predictability, token expiry, host header injection in reset emails, multi-use tokens
• OAuth/SSO: Redirect URI validation bypass, state parameter CSRF, token leakage through referrer headers, scope escalation

Phase 3: Authorization Testing

Authorization testing is where manual penetration testing provides the most value over automated scanning — and where we find the highest-severity vulnerabilities most consistently. Scanners cannot test authorization because they do not understand who should access what.

Horizontal Privilege Escalation (IDOR / BOLA)

The pentester authenticates as User A and systematically attempts to access User B's resources by manipulating identifiers — changing IDs in URLs, request bodies, and headers. In APIs using sequential integer IDs, this is as simple as incrementing /api/users/1234/documents to /api/users/1235/documents. In applications using UUIDs, the pentester looks for ID leakage in other endpoints, responses, or public-facing pages.

BOLA is the #1 vulnerability in the OWASP API Security Top 10 for a reason: it is extremely common, trivially exploitable, and results in direct data exposure. We find some form of IDOR in the majority of our web application assessments.

Vertical Privilege Escalation

The pentester authenticates as a low-privilege user and attempts to access administrative functionality — accessing admin endpoints directly, modifying role parameters in requests (mass assignment), or manipulating client-side role indicators that the server trusts without re-validation.

Function-Level Authorization (BFLA)

Can a regular user invoke administrative API functions? Can a read-only user call write endpoints? The pentester maps every endpoint and tests each one with every permission level to identify functions that check authentication but not authorization.

Phase 4: Input Validation and Injection

This is the phase where automated scanners contribute the most — and where manual testing adds depth in edge cases:

• Cross-Site Scripting (XSS): Reflected, stored, and DOM-based. Manual testing finds XSS in contexts scanners miss: within JSON responses rendered by JavaScript, in file upload filenames, in PDF generation from user input, in WebSocket messages, and in second-order contexts where input is stored and rendered on a different page
• SQL Injection: Beyond simple UNION-based injection, manual testing identifies blind SQL injection (boolean-based and time-based), second-order injection (input stored safely but used unsafely in a later query), and injection in parameters scanners do not test (HTTP headers, JSON fields, GraphQL variables)
• Server-Side Template Injection (SSTI): When user input is rendered through a template engine (Jinja2, Twig, Freemarker), attackers can execute arbitrary code on the server. SSTI is increasingly common in applications using template engines for email generation, PDF rendering, or dynamic page content
• Command Injection: Any functionality that interacts with the operating system — file conversion, image processing, DNS lookups, PDF generation — is a potential injection point

Phase 5: Business Logic Testing

Business logic flaws are the category that defines the difference between a vulnerability scan and a penetration test. These are vulnerabilities where the code works exactly as designed — but the design is exploitable.

Race Conditions

Sending concurrent requests to exploit time-of-check-to-time-of-use (TOCTOU) gaps. Common targets: applying a discount code multiple times simultaneously, transferring funds from an account faster than the balance check executes, or redeeming a single-use voucher in parallel requests. Race conditions frequently exist in financial operations, inventory management, and any feature involving a "check then act" pattern.

Price and Quantity Manipulation

If the client sends the price, the price is attacker-controlled. Testing includes modifying prices in cart operations, changing quantities to negative numbers (producing refunds), applying discounts that should not stack, and manipulating currency or unit parameters.

Workflow Bypass

Multi-step processes (registration, checkout, approval workflows) often assume users follow steps sequentially. Pentesters test skipping steps — submitting the final step directly, replaying earlier steps, and modifying state parameters that track progress through the workflow.

Phase 6: API-Specific Testing

Modern web applications are API-driven — the frontend is a thin client consuming REST, GraphQL, or gRPC endpoints. API-specific testing covers:

• Mass assignment: Sending extra parameters the API was not designed to accept (adding "role": "admin" or "verified": true to a profile update request)
• Rate limiting: Testing whether critical endpoints (login, password reset, MFA verification, API key generation) enforce rate limits that prevent brute-force attacks
• Excessive data exposure: APIs that return full database objects instead of the minimum fields needed — leaking internal IDs, email addresses, creation timestamps, or metadata that aids further attacks
• Improper inventory management: Old API versions (/api/v1/) still accessible alongside newer versions, with the older version lacking security controls added to /api/v2/

Chained Vulnerabilities: How Low-Severity Findings Become Critical

One of the most important aspects of manual penetration testing is vulnerability chaining — combining multiple low or medium-severity findings into a critical-impact attack chain. Scanners report individual findings in isolation. Pentesters think in attack paths.

Example chain we find regularly: An IDOR vulnerability that leaks user email addresses (medium severity on its own) is combined with a password reset flow that reveals whether an email exists (informational on its own) and a password reset token that is generated using a predictable timestamp-based algorithm (medium severity on its own). Individually, none of these are critical. Together, they enable full account takeover of any user in the system.

Another common chain: A self-XSS vulnerability that requires the victim to paste a payload into their own browser (typically informational/low) is combined with a CSRF vulnerability that forces the victim to update their profile. The attacker uses CSRF to inject a stored XSS payload into the victim's profile, which executes when an administrator views the user's account — stealing the admin's session token.

Automated Scan vs Manual Pentest

What a Pentest Report Should Include

The deliverable matters as much as the testing. A pentest report that engineering teams actually use to fix vulnerabilities should include:

• Executive summary: Overall risk posture in business language — what does this mean for the organization, not just a count of findings by severity
• Finding detail: For each vulnerability — description, affected endpoints, severity rating with justification, step-by-step proof of concept, screenshots, request/response captures, and CWE/OWASP classification
• Remediation guidance: Specific, code-level recommendations — not "sanitize user input" but "use parameterized queries in the /api/users endpoint's search functionality" with example code
• Retesting: Verification that remediated findings are actually fixed, not just moved to a different parameter or endpoint

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.