Web Application Security Testing Checklist: OWASP Top 10 Coverage and Beyond

You've just received your web application penetration test report. Twelve findings. Two critical. Four high. You remediate them, request retesting, and everything passes. Security sorted.

Six months later, a different testing provider finds eight new vulnerabilities. Three of them are in categories the first provider never tested: business logic flaws in your checkout workflow, an IDOR exposing other customers' invoices, and a race condition in your account balance transfer.

None of those appear in the OWASP Top 10. None would be caught by an automated scanner. None were in scope for the first provider's testing checklist because their checklist covered the OWASP Top 10 and stopped there.

The OWASP Top 10 is a starting point, not a finish line. It covers the most commonly exploited web application vulnerability categories, and every web application security test should cover them comprehensively. But applications processing financial transactions, health records, customer data, and enterprise workflows contain vulnerability classes that the OWASP Top 10 doesn't address: business logic manipulation, race conditions, multi-step workflow abuse, and application-specific authorisation failures that require understanding how your application is supposed to work.

This web application security testing checklist covers every OWASP Top 10 category with specific, actionable test cases, then goes beyond OWASP into the vulnerability classes that produce the highest-impact findings in professional web application penetration testing. Use it to evaluate your own application's security posture, scope testing engagements, verify your provider's coverage, and build security testing into your secure SDLC.

OWASP Top 10 (2021) Testing Checklist

A01: Broken Access Control

The number one web application vulnerability category. Broken access control allows users to act outside their intended permissions.

Horizontal privilege escalation (IDOR):

• Changing resource IDs in URLs/parameters doesn't expose other users' data
• Modifying object references in API requests doesn't return unauthorised records
• Sequential ID enumeration tested across all endpoints returning user-specific data
• UUID/GUID unpredictability validated (not sequential or time-based)
• File download endpoints don't allow path traversal to other users' files

Vertical privilege escalation:

• Standard users cannot access admin-only functionality by modifying URLs
• Role-based menu hiding is backed by server-side authorisation enforcement
• API endpoints enforce role checking, not just UI visibility
• Admin API endpoints not accessible by non-admin tokens
• Feature flags and premium functionality enforced server-side

Access control bypass:

• Direct object reference testing at every endpoint handling user data
• HTTP method manipulation (changing GET to POST, PUT, DELETE) doesn't bypass controls
• Path traversal in parameters doesn't access restricted resources
• Forced browsing to admin pages/endpoints blocked
• Access controls enforced after authentication state changes (role change, account downgrade)

Multi-tenancy isolation:

• Tenant A cannot access Tenant B's data through any endpoint
• Cross-tenant resource enumeration not possible
• Shared infrastructure doesn't leak data between tenants

A02: Cryptographic Failures

Failures relating to cryptography that expose sensitive data.

• All data transmitted over HTTPS (no HTTP fallback for sensitive operations)
• TLS 1.2 minimum enforced, TLS 1.3 preferred
• Strong cipher suites only (no RC4, DES, 3DES, export ciphers)
• HSTS header present with adequate max-age
• Sensitive data encrypted at rest (database, file storage, backups)
• Passwords hashed with modern algorithm (bcrypt, scrypt, Argon2) with adequate work factor
• No MD5 or SHA-1 for password hashing
• Encryption keys not hardcoded in source code or configuration files
• Key management follows established practices (rotation, separation, secure storage)
• Sensitive data not stored in cookies, local storage, or URL parameters
• Credit card numbers, SSNs, and PII not logged in application or web server logs
• Caching headers prevent sensitive response caching (Cache-Control: no-store)

A03: Injection

Injection flaws where hostile data is sent to an interpreter.

SQL injection:

• All database queries use parameterised queries or prepared statements
• Input containing SQL syntax (single quotes, UNION, OR 1=1) is handled safely
• Error messages don't reveal database structure or query details
• Second-order SQL injection tested (data stored then used in later queries)
• Blind SQL injection tested (time-based and boolean-based)

Cross-site scripting (XSS):

• Reflected XSS tested across all input parameters and URL paths
• Stored XSS tested in all user-generated content (profiles, comments, messages)
• DOM-based XSS tested in client-side JavaScript handling URL fragments and parameters
• Context-aware output encoding applied (HTML, JavaScript, URL, CSS contexts)
• Content Security Policy (CSP) header implemented and properly configured
• HttpOnly flag set on session cookies (preventing JavaScript access)
• XSS in file uploads tested (SVG, HTML files with embedded scripts)

Command injection:

• OS command injection tested where user input reaches system commands
• LDAP injection tested in directory lookups
• XML injection / XXE tested in XML parsing functionality
• SSTI (Server-Side Template Injection) tested where user input enters templates
• Header injection tested (CRLF injection in HTTP headers)
• Email header injection tested in contact forms and email functionality

A04: Insecure Design

Flaws in design and architecture rather than implementation.

• Threat model documented for critical application functionality
• Rate limiting implemented on authentication, registration, and password reset
• Business-critical transactions require re-authentication or step-up verification
• Multi-step workflows enforce expected sequence (no step-skipping)
• Sensitive operations require confirmation or out-of-band verification
• Error handling doesn't reveal internal architecture or technology stack
• Trust boundaries identified and enforced between application components
• Principle of least privilege applied across application functionality

A05: Security Misconfiguration

Insecure default configurations, missing hardening, or unnecessary features enabled.

• Default credentials removed from all application components
• Directory listing disabled on web server
• Unnecessary HTTP methods disabled (TRACE, OPTIONS returning excessive data)
• Stack trace and debug information not exposed in error responses
• Server version headers removed or obfuscated (Server, X-Powered-By)
• Admin interfaces not publicly accessible (restricted by IP or behind VPN)
• XML external entity (XXE) processing disabled where not needed
• CORS policy appropriately restrictive (not wildcard for sensitive endpoints)
• Cookie attributes configured (Secure, HttpOnly, SameSite)
• Security headers implemented:
  • Content-Security-Policy
  • X-Frame-Options or CSP frame-ancestors
  • X-Content-Type-Options: nosniff
  • Referrer-Policy
  • Permissions-Policy
• Unnecessary application features, documentation, and sample files removed
• Cloud service configurations hardened (S3 permissions, security groups)

A06: Vulnerable and Outdated Components

Using components with known vulnerabilities.

• All third-party libraries and frameworks inventoried
• Software Composition Analysis (SCA) identifying known CVEs in dependencies
• No components with critical known vulnerabilities in production
• Component update and patching process documented
• Unused dependencies removed
• Components sourced from official repositories (not modified or unofficial copies)
• Server-side frameworks and runtime updated to supported versions
• Client-side libraries (JavaScript) scanned for known vulnerabilities

A07: Identification and Authentication Failures

Authentication mechanisms that fail to properly verify identity.

Authentication testing:

• Brute-force protection enforced (account lockout or progressive delay)
• Default credentials not functional
• Password policy enforces adequate minimum length (12+ characters)
• Password breach database checking implemented (rejecting known compromised passwords)
• Multi-factor authentication available and properly implemented
• MFA bypass techniques tested (backup code brute-force, session fixation post-MFA)
• Account enumeration prevented (consistent responses for valid/invalid usernames)
• Timing attacks on authentication don't reveal valid accounts

Session management:

• Session tokens sufficiently random and unpredictable
• Session invalidated on logout (server-side invalidation, not just cookie deletion)
• Session timeout enforced after period of inactivity
• Session fixation not possible (new session ID issued after authentication)
• Concurrent session handling defined (new login invalidates old session)
• Session tokens transmitted only over HTTPS
• Session tokens not exposed in URLs, logs, or error messages

Password reset:

• Password reset tokens are single-use and time-limited
• Password reset doesn't reveal whether email/username exists
• Password reset link doesn't allow account takeover through token manipulation
• Old password required for password change (when user is authenticated)

A08: Software and Data Integrity Failures

Making assumptions about software updates and critical data without verification.

• Deserialization of untrusted data prevented or safely handled
• CI/CD pipeline integrity controls prevent unauthorised code injection
• Third-party library integrity verified (checksums, signed packages)
• Application doesn't auto-update from unverified sources
• Critical data integrity verified (digital signatures on sensitive documents or transactions)

A09: Security Logging and Monitoring Failures

Insufficient logging, detection, and response capability.

• Authentication events logged (successful and failed logins)
• Access control failures logged
• Input validation failures logged
• High-value transactions logged with sufficient detail
• Logs include timestamp, user identity, source IP, and event details
• Logs don't contain sensitive data (passwords, tokens, PII)
• Log tampering protections in place
• Alerting configured for suspicious activity patterns
• Log retention meets compliance requirements

A10: Server-Side Request Forgery (SSRF)

Application fetches remote resources without validating user-supplied URLs.

• User-controllable URLs validated against allowlist before server-side fetch
• Internal network addresses blocked in URL inputs (127.0.0.1, 10.x, 172.16-31.x, 169.254.x)
• Cloud metadata endpoints blocked (169.254.169.254)
• URL scheme restricted (http/https only, no file://, gopher://, dict://)
• DNS rebinding protections implemented
• SSRF tested in webhook functionality, URL preview features, and file import from URL

Beyond OWASP: Advanced Testing Checklist

The OWASP Top 10 covers the most common vulnerability categories. The following sections cover vulnerability classes that produce the highest-severity findings in professional penetration testing but aren't explicitly addressed in the Top 10.

Business Logic Testing

Business logic flaws are the highest-impact vulnerabilities that automated scanners fundamentally cannot detect. They require understanding how your application is supposed to work and testing what happens when that logic is violated.

• Price manipulation tested (modifying prices in requests for e-commerce)
• Quantity manipulation tested (negative quantities, zero-price items)
• Discount/coupon abuse tested (reuse, stacking, expired codes still functional)
• Multi-step workflow manipulation (skipping steps, reordering steps, repeating steps)
• Race conditions in financial operations (double-spending, balance manipulation)
• Business rule bypass (applying restricted actions through parameter modification)
• Referral/reward system abuse (self-referral, infinite reward loops)
• Rate limit bypass on business-critical operations
• Data validation bypass (submitting out-of-range values for business fields)
• Approval workflow circumvention (self-approving, skipping approval chains)
• Time-based manipulation (accessing features outside permitted windows)
• Feature abuse through unintended interaction between application components

Business logic testing is why manual penetration testing is essential. No automated tool understands your checkout workflow, approval process, or financial transaction logic well enough to test it.

API-Specific Testing

APIs power modern web applications and require testing beyond standard OWASP coverage.

• BOLA (Broken Object Level Authorisation) tested at every API endpoint
• BFLA (Broken Function Level Authorisation) tested across user roles
• Mass assignment tested (can users modify fields they shouldn't by adding parameters?)
• Excessive data exposure checked (APIs returning more data than the UI displays)
• Rate limiting enforced on API endpoints
• API versioning assessed (older versions with weaker security still accessible?)
• GraphQL introspection disabled in production (if using GraphQL)
• GraphQL depth limiting and query complexity controls
• API key/token scope validation (tokens can't access more than intended)
• Batch request abuse tested (single request processing multiple operations)

For comprehensive API testing, see our API penetration testing guide.

File Upload Security

• File type validation server-side (not just client-side extension checking)
• Magic byte validation confirming file content matches declared type
• Uploaded files scanned for malware
• Upload size limits enforced
• Uploaded files stored outside web root (not directly accessible via URL)
• Filename sanitisation preventing path traversal
• Image files re-processed to strip embedded metadata and potential exploits
• SVG uploads sanitised or restricted (can contain embedded JavaScript)
• Double extension bypasses tested (.php.jpg, .asp;.jpg)
• Content-Type header manipulation tested during upload

Client-Side Security

• Sensitive data not stored in browser localStorage or sessionStorage
• JavaScript source maps not deployed to production
• Client-side API keys not granting excessive permissions
• Postmessage communication validated (origin checking)
• WebSocket connections authenticated and authorised
• Client-side routing doesn't expose protected routes without server validation
• Third-party JavaScript inclusion audited for supply chain risk
• Subresource Integrity (SRI) on externally hosted scripts

Account and User Management

• Account registration doesn't allow email address abuse (unlimited accounts)
• Email verification enforced before account activation
• Account deletion actually removes data (not just soft-delete with accessible records)
• Profile update doesn't allow email takeover (changing email without verification)
• User enumeration not possible through registration, login, or password reset
• Account recovery doesn't expose personal information
• Invitation system doesn't allow privilege escalation (inviting yourself as admin)

Payment and Financial Transaction Security

• Payment amount validated server-side (not relying on client-submitted values)
• Currency manipulation tested
• Refund process doesn't allow exceeding original payment
• Payment completion can't be bypassed (accessing post-payment content without paying)
• Transaction atomicity ensured (partial failures don't create inconsistent state)
• Subscription manipulation tested (downgrade retaining premium features)
• Trial abuse tested (unlimited trial creation)

Infrastructure and Deployment

• Source code not exposed through publicly accessible repositories (.git, .svn)
• Backup files not accessible via web server (.bak, .old, .sql)
• Environment files not accessible (.env, .config, web.config)
• Development endpoints not present in production (debug, test routes)
• Error pages customised (no default framework error pages)
• robots.txt and sitemap.xml don't reveal sensitive paths
• Admin panels on separate subdomain or restricted network

Web Application Security Testing Checklist by Application Type

E-Commerce Applications

All standard checklist items above, plus:

• PCI DSS applicable controls validated for payment processing
• Shopping cart manipulation tested (price, quantity, discount)
• Checkout flow step-skipping tested
• Payment gateway integration tested for interception/manipulation
• Order status accessible only by order owner
• Gift card/voucher code security tested
• Inventory manipulation tested (negative quantities, reserved stock abuse)

SaaS Platforms

All standard checklist items above, plus:

• Tenant isolation validated across all data access paths
• Subscription tier enforcement server-side (feature access, usage limits)
• SSO/SAML integration tested for authentication bypass
• Webhook security tested (signature validation, SSRF prevention)
• API rate limiting per-tenant
• Data export doesn't include other tenants' data
• User role management doesn't allow privilege escalation within tenant

Healthcare Applications

All standard checklist items above, plus:

• PHI access controls validated (role-based, need-to-know)
• Audit trail for all PHI access comprehensive and tamper-resistant
• Patient data isolation between providers/facilities
• Emergency access ("break glass") procedures auditable
• HIPAA Security Rule technical safeguards validated

Financial Applications

All standard checklist items above, plus:

• Transaction signing/confirmation mechanisms tested
• Account balance manipulation tested
• Inter-account transfer authorisation validated
• Transaction limits enforced server-side
• Regulatory compliance controls validated (KYC, AML data protection)
• Statement and document access restricted to account owner

Using This Checklist Effectively

For Scoping Penetration Tests

Share relevant sections of this web application security testing checklist with your penetration testing provider during scoping. Confirm which items are in scope. Identify items requiring specific testing approaches (business logic tests need application documentation). Ensure the provider's methodology covers items beyond OWASP that apply to your application type.

For Evaluating Pentest Reports

After receiving your pentest report, map findings against this checklist. Identify which areas were tested and which were missed. Quality penetration testing reports should reference testing methodology covering at minimum all OWASP Top 10 categories plus business logic and authorisation testing.

Learn how to evaluate penetration testing quality using this checklist as a coverage baseline.

For Development Teams

Security champions can use category-specific sections during code review. Development teams can reference checklist items during feature design to build security in from the start rather than discovering issues during testing.

For Compliance

Map checklist items to compliance requirements. OWASP Top 10 coverage satisfies PCI DSS Requirement 6.5. Comprehensive coverage supports SOC 2 Trust Services Criteria. ISO 27001 Annex A.8.25 (Secure Development) and A.8.26 (Application Security Requirements) align with this checklist's coverage.

For full compliance mapping, see our penetration testing compliance guide.

How AppSecure Tests Beyond the Checklist

AppSecure's web application penetration testing covers every item in this checklist and discovers vulnerabilities specific to your application that no generic checklist contains.

Complete OWASP Top 10 Coverage

Every OWASP Top 10 category tested with multiple techniques. Broken access control tested at every endpoint. Injection tested across every input vector. Authentication, session management, and cryptography validated comprehensively.

Business Logic Expertise

AppSecure's testers understand application workflows and test what happens when business logic is violated. Price manipulation, workflow bypass, race conditions, and application-specific abuse scenarios that automated scanners and generic checklists miss.

Zero False Positives

Every finding is manually validated through exploitation with proof-of-concept evidence. Your development team receives genuine, exploitable vulnerabilities to fix, not scanner noise.

Beyond Web Applications

API testing, mobile testing, cloud testing, and network testing provide full-stack coverage beyond web application scope. Application security assessment and offensive security testing deliver end-to-end validation.

3-Week Delivery

Standard web application penetration testing engagements deliver within three weeks. 90-day remediation support and complimentary retesting included. Continuous penetration testing and PTaaS provide ongoing web application security validation.

Ready for web application security testing that goes beyond the checklist?

Contact AppSecure:

• Schedule Web Application Testing
• Application Security Assessment
• Web Application Penetration Testing Guide

Frequently Asked Questions

1. What is a web application security testing checklist?

A web application security testing checklist is a structured list of security tests to perform against a web application to identify vulnerabilities. A comprehensive checklist covers every OWASP Top 10 vulnerability category (broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, data integrity failures, logging failures, and SSRF) plus advanced testing areas including business logic, API security, file upload security, and client-side security. Checklists help ensure consistent coverage across testing engagements and prevent critical vulnerability categories from being missed.

2. What does the OWASP Top 10 cover and what does it miss?

The OWASP Top 10 covers the most critical web application vulnerability categories: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, software integrity failures, logging failures, and SSRF. The Top 10 is a starting point covering common vulnerability patterns. It doesn't explicitly address business logic flaws (price manipulation, workflow bypass, race conditions), application-specific authorisation failures, payment processing vulnerabilities, or multi-step workflow abuse. These "beyond OWASP" categories consistently produce the highest-impact findings in professional penetration testing.

3. How many test cases should a web application security test include?

A comprehensive web application security test should cover at minimum all OWASP Top 10 categories with multiple test cases per category (100+ items for OWASP coverage alone). Adding business logic, API, file upload, client-side, and application-type-specific testing brings comprehensive coverage to 200+ test cases. This checklist contains 250+ actionable items. However, quantity alone doesn't ensure quality. Manual testing by experienced professionals discovers vulnerabilities that systematic checklists miss because they're specific to your application's unique functionality.

4. Can automated scanners cover this checklist?

Automated scanners cover portions of the OWASP Top 10: injection testing (A03), security misconfiguration detection (A05), vulnerable component identification (A06), and some cryptographic failure detection (A02). Scanners cannot test business logic flaws, complex authorisation failures (IDOR requiring understanding of data ownership), multi-step workflow manipulation, race conditions, or application-specific abuse scenarios. Roughly 40 to 50 percent of this checklist requires manual testing by security professionals. The highest-impact findings (business logic, authorisation bypass) are consistently in the manual-only category.

5. How does this checklist relate to PCI DSS compliance?

PCI DSS Requirement 6.5 requires protection against common web application vulnerabilities mapped to OWASP Top 10. This checklist's OWASP section directly addresses Requirement 6.5 coverage. Requirement 6.4 requires web application firewall or application security review. Requirement 11.3 requires annual penetration testing that should use this checklist as minimum coverage scope. E-commerce-specific items address payment processing security relevant to Requirement 3 (cardholder data protection) and Requirement 4 (encrypted transmission).

6. What is the difference between a security testing checklist and a penetration test?

A security testing checklist defines what to test. A penetration test is the professional engagement where expert testers execute those tests against your specific application using manual techniques and professional tools. The checklist ensures coverage. The penetration test provides the expertise, creativity, and exploitation skills to discover and validate vulnerabilities. Checklists catch known patterns. Expert testers discover application-specific vulnerabilities requiring human understanding of your unique business logic and architecture.

7. How often should web application security testing be conducted?

Annual web application security testing satisfies most compliance requirements. Applications processing sensitive data (financial, health, PII) warrant semi-annual or quarterly testing. Testing should also occur after major releases, significant feature additions, architecture changes, and framework upgrades. Applications with high deployment velocity benefit from continuous testing through PTaaS. Each major release introducing new functionality should be tested before or shortly after production deployment.

8. What should developers use this checklist for?

Developers can use this checklist during code review to verify that common vulnerability patterns are addressed, during feature design to incorporate security requirements from the start, and during testing to validate their own code before professional security assessment. Security champions can use category-specific sections as review guides. The checklist also helps development teams understand what penetration testers will evaluate, setting expectations for professional assessment findings.

9. Which sections matter most for SaaS applications?

SaaS applications should prioritise A01 (Broken Access Control) for tenant isolation and user role enforcement, A07 (Authentication Failures) for SSO and session management, the business logic section for subscription and feature enforcement, and the API-specific section since most SaaS platforms are API-driven. Tenant isolation testing is the most critical SaaS-specific test: verifying that Tenant A cannot access Tenant B's data through any endpoint, parameter manipulation, or API request.

10. How do I verify my pentest provider covers this checklist?

During scoping, share relevant checklist sections and confirm which items fall within testing scope. Request that the provider's methodology document maps to OWASP Top 10 categories at minimum. After receiving the report, verify that findings reference testing across all agreed categories. If the report only contains automated scanner output without business logic testing, authorisation testing, or manual exploitation evidence, the provider likely didn't cover the full checklist. Quality providers should be able to describe their testing approach for every major category.