Web application penetration testing: the 47-test checklist we actually use

This is the working test plan our engineers open on day one of every web application engagement. 47 line items, grouped into ten categories. Use it as a self-test against your own application, or as a reference for what to ask of a VAPT vendor.

1. Authentication (6 tests)

• Login brute-force — is there account lockout, rate-limit, or CAPTCHA after N failed attempts?
• Username enumeration via login (different error for valid vs invalid user) and via forgot-password.
• Password policy — minimum length, complexity, blocklist of common passwords.
• Forgot-password token — entropy (at least 128 bits), expiry (≤ 1 hour), single-use, bound to user.
• Multi-factor authentication — can it be bypassed, replayed, or downgraded? Is the OTP delivered out-of-band?
• OAuth / SSO — state parameter present and validated, redirect URI strict-matched, PKCE on public clients.

2. Session management (5 tests)

• Session token — generated server-side, sufficient entropy, regenerated on auth.
• Cookies — HttpOnly, Secure, SameSite=Lax or Strict.
• Logout — server-side invalidation, not just client cookie clear.
• Concurrent sessions — policy enforced, especially for admin roles.
• JWT (if used) — algorithm pinned, no alg:none, signature verified, exp claim enforced.

3. Access control / authorization (6 tests)

• Horizontal IDOR — does swapping a resource ID give access to another user's resource?
• Vertical privilege escalation — can a regular user invoke admin endpoints by URL guessing?
• Tenant isolation — can tenant A access tenant B's data via direct ID, search filter, or report export?
• Forced browsing — direct access to hidden URLs (/admin, /internal, /debug).
• API method override — can POST be tunneled through X-HTTP-Method-Override: PUT?
• Mass assignment — can a normal user set isAdmin=true in a profile update?

4. Input validation / injection (6 tests)

• SQL injection — every parameter, including HTTP headers and cookies. Both error-based and time-based blind.
• NoSQL injection — MongoDB operator injection ({"$gt":""}) in JSON bodies.
• XSS — reflected, stored, DOM-based. Test JSON sinks rendered as HTML.
• Command injection — features that touch the OS (file conversion, PDF generation, ping/network features).
• Template injection — Server-Side Template Injection on email templating, report builders.
• XXE — XML parsers that allow external entities; SOAP services and SVG file uploads.

5. Business logic (5 tests)

• Workflow bypass — can a multi-step flow be entered at step 3 by URL-skipping step 2?
• Negative-value attacks — quantity = -1 in cart, refund = -INR 5000.
• Race conditions — same-coupon redemption in parallel, same-balance double-spend.
• Rate-limited operations bypassed via parallelism or different paths to the same operation.
• Approval bypass — can a "pending approval" status be edited client-side to "approved"?

6. File upload (4 tests)

• Content-Type vs magic-byte vs extension — which does the server trust?
• Polyglot files — JPEG with embedded PHP, SVG with embedded JavaScript.
• Path traversal in filename — ../../etc/passwd survives unsanitised concatenation.
• Storage location — uploaded files served from a domain that executes them?

7. SSRF and external requests (3 tests)

• Direct SSRF — does any feature accept a URL and fetch it server-side?
• DNS rebinding to bypass IP allow-lists.
• Cloud metadata access — 169.254.169.254, metadata.google.internal, IMDSv1 vs v2.

8. CSRF, CORS, clickjacking (3 tests)

• State-changing endpoints — CSRF token present, validated, bound to session.
• CORS — Access-Control-Allow-Origin: * with Allow-Credentials: true is exploitable.
• Clickjacking — X-Frame-Options or Content-Security-Policy: frame-ancestors.

9. Cryptography (3 tests)

• TLS — TLS 1.2+ only, no weak ciphers, valid cert chain.
• Sensitive fields encrypted at rest with envelope encryption, not application-layer obfuscation.
• Custom tokens — no ECB mode, no constant IVs, no static keys checked into the repo.

10. Information disclosure (6 tests)

• Verbose error pages with stack traces, framework versions, DB queries.
• Debug endpoints — /actuator, /_debug, /graphiql in production.
• robots.txt and sitemap.xml revealing internal paths.
• Source map files (.js.map) on the CDN.
• Backup files left on the web root (.bak, .zip, .sql).
• Sensitive data in URL parameters — captured by logs, referrer headers, browser history.

For the underlying methodology, see our approach. For the API equivalent of this list, see the API security guide.