Web Application Security Testing Checklist for 2026

Published April 7, 2026 · 12 min read

This is the checklist I wish I'd had when I started testing web applications. Not a theoretical framework — a practical list of what to test, in what order, with what tools, and what to look for.

It's organized around the OWASP Top 10 (2021) because that's still the standard in 2026, but it goes beyond the Top 10 into areas that matter in practice: security headers, TLS configuration, API-specific testing, and supply chain concerns.

Phase 1: Reconnaissance

Before testing anything, understand what you're testing. Recon isn't optional — it determines the scope and focus of everything that follows.

Technology Stack Identification

• ☐ Identify web server (Apache, Nginx, IIS, Cloudflare)
• ☐ Identify application framework (React, Next.js, Django, Rails, Spring)
• ☐ Identify backend language (response headers, error pages, file extensions)
• ☐ Check for WAF presence (Cloudflare, AWS WAF, Akamai, Imperva)
• ☐ Enumerate subdomains and virtual hosts

Endpoint Discovery

• ☐ Spider/crawl the application (ZAP Spider, Burp Crawler)
• ☐ Check for exposed API documentation (Swagger/OpenAPI at /api-docs, /swagger.json, /openapi.json)
• ☐ Analyze JavaScript bundles for hidden endpoints and API keys
• ☐ Directory brute-force common paths (/admin, /api, /.env, /.git)
• ☐ Check robots.txt and sitemap.xml for disclosed paths

Tools: OWASP ZAP (spider), Burp Suite (crawler), ffuf (directory brute-force), Nuclei (tech detection templates). For a comparison of ZAP vs Burp, see our detailed comparison.

Phase 2: Injection Testing

Injection remains the most exploited vulnerability class. Test every user-controlled input.

SQL Injection (OWASP A03)

• ☐ Test all parameters (GET, POST, headers, cookies) with single quote (') and observe error responses
• ☐ Test error-based SQLi: look for database error signatures (MySQL, PostgreSQL, MSSQL, SQLite)
• ☐ Test boolean-based SQLi: compare response lengths for AND 1=1 vs AND 1=2
• ☐ Test time-based blind SQLi: SLEEP(5), pg_sleep(5), WAITFOR DELAY
• ☐ Check ORM-layer injection (parameterized queries can still be vulnerable if built with string concatenation)

For a deep dive, see Detecting SQL Injection: What Your Scanner Should Check in 2026.

Cross-Site Scripting — XSS (OWASP A03)

• ☐ Test reflected XSS: inject <script>alert(1)</script> in all parameters and check if it appears unencoded in the response
• ☐ Test attribute injection: " onmouseover="alert(1) in parameters reflected inside HTML attributes
• ☐ Test DOM-based XSS: check document.location, document.referrer, window.name sinks
• ☐ Test stored XSS: submit payloads in forms, comments, profile fields — check if they render for other users
• ☐ Check Content-Security-Policy effectiveness against XSS payloads

For a deep dive, see Detecting Reflected XSS: What Your Scanner Should Check in 2026.

Server-Side Request Forgery — SSRF (OWASP A10)

• ☐ Test URL parameters for SSRF: inject http://169.254.169.254/latest/meta-data/ (AWS metadata)
• ☐ Test for internal network access: http://localhost, http://127.0.0.1, http://[::1]
• ☐ Test file:// protocol: file:///etc/passwd
• ☐ Check for DNS rebinding bypass potential
• ☐ Test webhook/callback URL fields — these are common SSRF vectors

Command Injection

• ☐ Test parameters that might reach system commands: ; id, | id, $(id), `id`
• ☐ Check file upload functionality for command injection via filenames
• ☐ Test PDF/image generation features (often shell out to external tools)

Phase 3: Authentication & Access Control

Authentication (OWASP A07)

• ☐ Test for username enumeration (different responses for valid vs invalid usernames)
• ☐ Test account lockout after failed attempts (or lack thereof)
• ☐ Check password policy enforcement (minimum length, complexity)
• ☐ Test password reset flow for token predictability and expiration
• ☐ Check session cookie flags: Secure, HttpOnly, SameSite
• ☐ Test for session fixation (does the session ID change after login?)
• ☐ Check JWT implementation: algorithm confusion (none/HS256), weak secrets, missing expiration

Access Control (OWASP A01)

• ☐ Test IDOR: change resource IDs in URLs and API calls to access other users' data
• ☐ Test horizontal privilege escalation: access another user's resources with your session
• ☐ Test vertical privilege escalation: access admin endpoints with a regular user session
• ☐ Check for missing function-level access control on API endpoints
• ☐ Test direct object references in file downloads, exports, and reports

Phase 4: Configuration & Headers

Security Headers (OWASP A05)

• ☐ Content-Security-Policy — present and restrictive (no unsafe-inline, no unsafe-eval)
• ☐ X-Frame-Options — DENY or SAMEORIGIN (prevents clickjacking)
• ☐ X-Content-Type-Options: nosniff — prevents MIME type sniffing
• ☐ Strict-Transport-Security — present with max-age ≥ 31536000
• ☐ Referrer-Policy — strict-origin-when-cross-origin or stricter
• ☐ Permissions-Policy — restricts browser features (camera, microphone, geolocation)

CORS Configuration

• ☐ Check Access-Control-Allow-Origin — should not be * with credentials
• ☐ Test origin reflection: does the server reflect any origin back in the CORS header?
• ☐ Check Access-Control-Allow-Credentials: true with permissive origins

Information Disclosure

• ☐ Check for verbose error messages (stack traces, database errors, file paths)
• ☐ Check Server header for version disclosure
• ☐ Check for exposed .env, .git, web.config, phpinfo.php
• ☐ Check for debug mode indicators (DEBUG=True, development error pages)

Phase 5: Cryptography & TLS

TLS Configuration (OWASP A02)

• ☐ TLS version: 1.2 minimum, 1.3 preferred. Flag TLS 1.0/1.1.
• ☐ Cipher suites: no RC4, DES, 3DES, export-grade ciphers
• ☐ Certificate: valid, not expired, correct hostname, not self-signed
• ☐ HSTS: present with adequate max-age
• ☐ Certificate transparency: check CT logs for unexpected certificates

For a deep dive, see How to Audit TLS Configuration.

Phase 6: Components & Supply Chain

Vulnerable Components (OWASP A06)

• ☐ Identify all client-side libraries (jQuery, React, Angular, Bootstrap) and their versions
• ☐ Cross-reference against known CVEs (Snyk, NVD, GitHub Advisory Database)
• ☐ Check for outdated server-side frameworks (visible in headers, error pages, or fingerprinting)

Supply Chain (OWASP A08)

• ☐ Check Subresource Integrity (SRI): all CDN-loaded <script> and <link> tags should have integrity attributes
• ☐ Verify CDN sources are legitimate (no typosquatting domains)
• ☐ Check for inline scripts that could be replaced by CSP-compliant external files

Phase 7: API-Specific Testing

If the application exposes APIs (REST, GraphQL, gRPC), add these checks:

• ☐ Test rate limiting on authentication endpoints
• ☐ Test for mass assignment (send extra fields in POST/PUT requests)
• ☐ Test GraphQL introspection (should be disabled in production)
• ☐ Test for excessive data exposure (API returns more fields than the UI displays)
• ☐ Check API versioning — are old, deprecated endpoints still accessible?
• ☐ Test pagination for data leakage (can you enumerate all records?)

Tool Recommendations

For detailed tool comparisons, see ZAP vs Burp Suite and Nuclei vs Traditional Scanners. For CI/CD integration, see Automating ZAP in GitHub Actions.

The Checklist (Copy-Paste Ready)

Here's the condensed version you can paste into your testing notes:

## Web App Security Test Checklist

### Recon
- [ ] Tech stack identified (server, framework, language, WAF)
- [ ] Endpoints discovered (spider, API docs, JS analysis, directory brute-force)

### Injection (A03)
- [ ] SQLi tested (error-based, boolean-based, time-based)
- [ ] XSS tested (reflected, stored, DOM-based)
- [ ] SSRF tested (metadata endpoints, localhost, file://)
- [ ] Command injection tested (where applicable)

### Auth & Access (A01, A07)
- [ ] Username enumeration checked
- [ ] Account lockout tested
- [ ] Session management reviewed (cookie flags, fixation, JWT)
- [ ] IDOR tested on all resource endpoints
- [ ] Privilege escalation tested (horizontal + vertical)

### Config & Headers (A05)
- [ ] Security headers checked (CSP, X-Frame-Options, HSTS, etc.)
- [ ] CORS configuration tested
- [ ] Information disclosure checked (errors, headers, exposed files)

### Crypto & TLS (A02)
- [ ] TLS version and cipher suites checked
- [ ] Certificate validity confirmed
- [ ] HSTS present

### Components & Supply Chain (A06, A08)
- [ ] Client-side libraries version-checked against CVEs
- [ ] SRI present on CDN-loaded resources
- [ ] Server-side components fingerprinted

### API-Specific
- [ ] Rate limiting tested
- [ ] Mass assignment tested
- [ ] GraphQL introspection checked
- [ ] Excessive data exposure checked

Bottom Line

A security test is only as good as its coverage. This checklist won't catch everything — business logic flaws, race conditions, and complex authorization bugs require manual analysis and domain knowledge. But it will catch the vulnerabilities that scanners and structured testing are designed to find.

Start with recon. Test injection on every input. Check the configuration. Verify the crypto. Scan the components. That covers 80% of what goes wrong in web applications.

For automated coverage of most of these checks, see our SecurityClaw OWASP Top 10 coverage analysis.