Web App Penetration Testing Checklist 2026

A web application penetration testing checklist is not a list of tools to run — it is a map of the attack surface, in the order an attacker explores it. The difference between a useful checklist and a useless one is whether it helps you find the findings that cost money when they break. The OWASP Top 10 is a starting point; the 2026 realities of GraphQL APIs, server-side rendering, WebAssembly runtimes, and AI-integrated features have pushed the real attack surface well beyond it. This is the checklist we use internally at RingSafe for grey-box engagements in 2026, organized by phase, with notes on what actually matters versus what looks good on the report.

Phase 1 — Reconnaissance and mapping

Before testing anything, map what is actually there. Applications lie about their scope; a tester who believes the documented endpoint list will miss half the attack surface.

Enumerate all routes. Crawl authenticated and unauthenticated as every role. Pull routes from JavaScript bundles, source maps (if leaked), Swagger / OpenAPI specs, and sitemap.xml. Tools: Burp Suite Pro, Katana, ffuf, JSFinder.
Identify technology stack. Framework, backend language, web server, CDN, auth provider, payment processor. Wappalyzer is the surface read; look at response headers, cookie names, error-page fingerprints, and static asset paths for the real stack.
Map authentication flows. Every login method — password, SSO, magic link, OAuth, SAML, API key, mobile OTP. Note session lifetime, refresh-token semantics, and logout invalidation.
Identify all user roles and privilege boundaries. Not just “admin and user” — tenant-admin, org-admin, read-only, service accounts, impersonation flows, support-team shadow logins. This is where most of the real findings live.
List all external integrations. Payment gateways, email/SMS providers, analytics, CDN, third-party APIs, webhooks. Every integration is a trust boundary.
Check for accidentally exposed environments. Staging/dev subdomains on production DNS, internal APIs exposed through CORS misconfigurations, backup archives in S3, admin interfaces reachable without VPN. Use Subfinder, Amass, and passive DNS sources.

Phase 2 — Authentication testing

Authentication bugs are high-severity by nature because they bypass every subsequent control. Do these before anything else.

Username enumeration via error-message delta (login, password reset, registration). Timing-based enumeration — same-length responses, different response times.
Password policy enforcement. Minimum length, complexity, known-compromised-password check (HIBP k-anonymity integration is now table stakes).
Rate limiting on login, password reset, MFA verification. Per-account and per-IP. Bypass attempts via X-Forwarded-For, distributed IPs, and username rotation.
Account lockout and unlock flows — is the unlock itself rate-limited?
Password reset token entropy and reuse. One-time enforcement. Token leak via Referer header, logs, or email-quoting in follow-ups.
MFA implementation — TOTP seed management, SMS fallback security, backup-code storage, enrolment bypass. Post-auth MFA (session-upgrade) for sensitive operations.
SSO / SAML: signature validation, audience restriction, replay protection, XML external entity injection on response parsing, relay-state tampering.
OAuth: state parameter presence, PKCE enforcement (public clients), redirect_uri whitelisting, scope upgrade attacks, authorization-code leakage.
Session handling: cookie flags (Secure, HttpOnly, SameSite=Lax/Strict), session fixation, concurrent-session handling, logout-side-effect completeness (server-side session kill, not just cookie delete).
JWT validation: algorithm confusion (HS256 vs RS256), “none” algorithm, signature-bypass, key-confusion, expired-token acceptance, kid header injection.

Phase 3 — Authorization testing

Authorization is where modern web apps break. The framework can handle authentication; authorization is almost always application-specific and therefore almost always buggy.

Horizontal IDOR across every resource identifier. Swap tenant IDs, user IDs, order IDs, document IDs between accounts. Test on every HTTP verb, not just GET.
Vertical privilege escalation. Low-privilege user attempting high-privilege endpoints. Check both the URL-level authorization and object-level authorization — failing either is a finding.
Mass assignment. User updates own profile; try to set role: admin, tenant_id: different, verified: true in the JSON body.
Forced browsing. Admin routes reachable by low-privilege users because frontend hides them but backend does not enforce.
Tenant-boundary violations. The multi-tenant killer. Verify every query, every cache key, every file access includes tenant_id in the filter. Look especially at async jobs, webhooks, and bulk operations.
Function-level authorization on GraphQL. Every resolver must authorize independently; a vulnerable resolver reachable via a nested query is still reachable.
Impersonation flows. Customer-support “login as user” features. Who can invoke? Is it logged? Is there a prompt-forced-reauth? Is an audit trail visible to the impersonated user?

Phase 4 — Input validation and injection

SQL injection — classic, blind, time-based, second-order. Every input that touches a query, including Headers, Cookies, and multipart form fields.
NoSQL injection — operator injection ($ne, $gt), JavaScript injection on MongoDB $where, Redis CRLF injection.
Command injection — any input that ends up in exec, system, or shell invocation. File processors, image converters, PDF generators, and archive handlers are high-yield targets.
Server-side template injection. Test Jinja2, Twig, ERB, Handlebars, Velocity, FreeMarker based on fingerprinted stack.
Cross-site scripting — reflected, stored, DOM-based. Modern SPAs and React apps still have XSS; look at dangerouslySetInnerHTML, Markdown renderers, and user-supplied HTML in rich-text fields.
XML external entity (XXE) injection — anywhere XML is parsed, including SOAP, SAML, DOCX, SVG, and RSS feed consumers.
Server-side request forgery (SSRF). Image preview fetchers, webhook testers, PDF generators fetching remote CSS, OAuth discovery endpoints. Cloud metadata service access is the classic payload (169.254.169.254 on AWS; look for IMDSv2 enforcement).
Path traversal in file upload, download, and archive-extraction endpoints. Zip-slip in ZIP/TAR extraction. Unicode normalization bypasses.
HTTP request smuggling where proxies and origins disagree on Content-Length vs Transfer-Encoding. Less common post-HTTP/2 adoption but still surfaces in mixed stacks.
Prompt injection — now standard in 2026 for any AI-integrated feature. Direct prompt injection via user input; indirect via documents, URLs, or retrieved content. Test whether untrusted data can escalate model permissions or exfiltrate system prompts.

Phase 5 — Business logic

No scanner finds these. This is the tester-dependent part of the engagement and where the commercially-important findings live.

Race conditions in financial operations. Concurrent-request attacks on balance deduction, coupon redemption, refund processing, withdrawal limits. Turbo Intruder is the standard tool; any finding here is typically critical severity.
Workflow skipping. Multi-step processes where intermediate validations are frontend-only. KYC workflows, checkout flows, onboarding flows — try posting directly to the final step.
Price manipulation. Negative quantities, decimal precision exploits, currency mismatches, discount-stacking beyond the intended cap, coupon reuse.
Quota and rate-limit bypass in tenant-plan enforcement. Can a free-tier user upgrade themselves to paid by bypassing the plan check on an internal endpoint?
Referral abuse. Self-referral, synthetic-account chains, referrer-payout gaming, coupon-only-for-first-order enforcement.
Time-of-check vs time-of-use. Any operation that reads state, validates, then mutates has a window. Sensitive for role changes, subscription status, and feature flags.

Phase 6 — Session, cookie, and header review

Cookie security flags — already mentioned but verify at every endpoint.
HTTP security headers: CSP (not just default-src; verify script-src, object-src, no unsafe-inline unless nonce-protected), HSTS with preload, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
CORS misconfiguration — origin reflection, null origin acceptance, wildcard with credentials.
CSRF protection on state-changing endpoints. SameSite=Lax is helpful but not sufficient; explicit CSRF token required for cross-origin dangerous operations.
Subresource Integrity on externally-hosted scripts.
Clickjacking — X-Frame-Options or CSP frame-ancestors on sensitive views.

Phase 7 — File handling

Upload file-type validation — MIME sniffing vs extension vs magic-number check. Server must enforce at content inspection, not at filename.
Image parser vulnerabilities — ImageMagick, Pillow, libjpeg-turbo. Test with polyglot files that have been weaponized historically.
File storage location and access control. Uploaded files accessible via predictable URLs? Signed URLs with proper expiry? Hotlinking protection?
Download controls — authentication enforcement on static assets that contain PII or sensitive documents.
Office and PDF parsing — macro execution in backend previewers, embedded JavaScript in PDFs.

Phase 8 — Third-party and supply chain

Frontend dependency audit — npm audit or Snyk output on package-lock.json. Known-vulnerable versions in production bundles.
Backend dependency audit — same for pip, go modules, maven, bundler.
Third-party script loading — payment gateway scripts, analytics, chat widgets. What can they do if compromised? Subresource Integrity? CSP scope?
Embedded iframes — from trusted third parties but still potentially compromised. Audit permissions granted and data shared.
Secret scanning in public artifacts — bundled JavaScript for leaked API keys, service credentials, or internal URLs.

Phase 9 — API-specific testing

If the app is an SPA or mobile-backed product, the API carries most of the real risk. Run the OWASP API Security Top 10 2023 checklist in full — it is a separate methodology, not a subset of web testing. We cover it in depth in our API Security Testing guide.

Phase 10 — Documentation and reporting

Not optional. A finding without evidence is a claim. Every finding in a deliverable report must include: reproduction steps, HTTP request/response pair, screenshots where relevant, affected component, attack prerequisites, and specific remediation named at the file-and-function level. Attack chains across multiple findings are narrated as chains, not listed as independent items.

The findings that most often matter commercially

After hundreds of engagements, a pattern emerges. If your web app penetration test did not specifically look for these, you probably got a scan with extra steps:

Horizontal IDOR on a multi-tenant resource (customer data disclosure)
Mass assignment on user or subscription update (privilege escalation)
Broken authorization on GraphQL nested resolver (data disclosure)
Race condition in refund or credit flow (direct financial loss)
SSRF to cloud metadata service (cloud credential compromise)
XSS in customer-facing field that admins view (admin session theft)
Prompt injection in AI-assisted feature returning tool outputs (data exfiltration)

None of these are exotic. All of them are missed by automated scanners. All of them are findings whose discovery in a penetration test has directly prevented breaches we later saw hit peer organizations.

Tools — but tools are not methodology

The standard tool stack for 2026 web app testing: Burp Suite Professional (dominant), Caido (rising), OWASP ZAP (free alternative), ffuf (directory and parameter fuzzing), Nuclei (templated vulnerability checks), SQLMap (targeted SQLi exploitation), Turbo Intruder (race conditions), JSLuice or JSFinder (JS-bundle analysis), Katana (crawling), Subfinder + Amass (subdomain enumeration), Trufflehog (secret scanning).

Tooling is 20% of a competent pentest. The remaining 80% is the tester’s ability to read the application, form hypotheses about where business logic will break, and construct proof-of-concept attacks. Checklists like this one are scaffolding — they keep you honest about coverage, not a substitute for the thinking.

Web Application Penetration Testing Checklist (OWASP 2026)