Written by the Infronest Security Research Team — certified security professionals (CEH, OSCP, BSCP, GWAPT) with 10+ years of hands-on delivery. All technical content reviewed against OWASP Testing Guide v4.2, PTES, and NIST SP 800-115.
Security & Compliance
Web Application Penetration Testing: The Complete Checklist (2026)
A practitioner-grade checklist covering every phase of a web application penetration testing engagement, from pre-test scoping to OWASP Top 10 coverage, API testing, and final report requirements.
Web applications are the most exploited attack surface in modern IT environments. Verizon DBIR 2025 confirms that web application attacks are involved in the majority of confirmed data breaches, and IBM's Cost of a Data Breach Report 2025 confirms that customer PII is compromised in 53 percent of all breaches — the exact data that web applications handle. A structured web application penetration testing engagement finds those vulnerabilities before attackers do. This checklist covers every area a professional engagement must test.
Definition
What is web application penetration testing?
Web application penetration testing is an authorised, manual security assessment of a web application in which a certified tester attempts to exploit vulnerabilities in authentication, input handling, session management, business logic, and API endpoints to demonstrate what a real attacker could access, modify, or steal.
Before you start
Pre-test requirements checklist
Before testing begins, confirm every item below is in place. Missing any of these will compromise the quality of findings or create legal exposure:
- Written scope agreement signed by both parties — defines in-scope URLs, subdomains, and APIs
- Testing environment agreed — production, staging, or dedicated test instance
- Test accounts provisioned — at minimum one account per privilege level in scope
- WAF and rate-limiting status confirmed — should it be bypassed or avoided?
- Notification contacts agreed — who receives an immediate alert if a Critical vulnerability is found
- Backup status verified — in case any test action causes data modification
- Test methodology agreed — black-box, grey-box, or white-box
1. Information gathering and reconnaissance
- Enumerate all application entry points: forms, URL parameters, headers, cookies
- Map all application functionality including hidden or unauthenticated paths
- Identify technology stack: web server, framework, database, CDN, WAF
- Review robots.txt, sitemap.xml, and source code comments for sensitive disclosure
- Check for exposed Git repositories, backup files, and admin interfaces
- Identify all third-party integrations and their data flows
2. Authentication testing
- Test for username enumeration via login error messages or response-time differences
- Verify lockout policy after failed login attempts
- Test multi-factor authentication bypass techniques
- Check for password strength enforcement and breach-password detection
- Test OAuth and SSO implementations for token leakage and redirect vulnerabilities
- Verify session token randomness and entropy (minimum 128 bits)
- Test login over HTTP and mixed-content authentication flows
3. Session management
- Confirm session tokens are invalidated on logout
- Test for session fixation vulnerabilities
- Verify session timeout policy is enforced server-side
- Check that session tokens are not transmitted in URLs
- Test for CSRF in all state-changing requests
- Verify SameSite, Secure, and HttpOnly cookie attributes are set correctly
4. Input validation and injection
This checklist covers all 10 OWASP Top 10 2021 categories: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Authentication Failures, A08 Data Integrity Failures, A09 Logging Failures, A10 SSRF.
- SQL injection in all database-connected parameters — manual and automated
- NoSQL injection in MongoDB, CouchDB, and other document databases
- Cross-site scripting (XSS) — reflected, stored, and DOM-based in all input fields
- XML External Entity (XXE) injection in XML-processing endpoints
- Server-Side Request Forgery (SSRF) in URL or file-fetching functionality
- Command injection in any functionality that calls OS commands
- Template injection in server-side rendering functions
- Path traversal in file upload, download, and inclusion features
5. Access control and authorisation
- Test for Insecure Direct Object References (IDOR) by modifying resource identifiers
- Verify horizontal privilege escalation — can one user access another user's data?
- Verify vertical privilege escalation — can a low-privilege user access admin functions?
- Test forced browsing to restricted paths
- Check for Mass Assignment vulnerabilities in object creation and update endpoints
6. API security testing
- Document all API endpoints using active crawling and spec files (OpenAPI, Swagger)
- Test authentication on every API endpoint — not just the login flow
- Test for Broken Object Level Authorization (BOLA) across all API resources
- Test for Broken Function Level Authorization — can users call admin-only API methods?
- Check for excessive data exposure in API responses
- Test rate limiting and throttling on authentication and sensitive endpoints
- Verify that internal API endpoints are not exposed to external users
7. Business logic testing
- Test purchase flows for price manipulation, quantity bypass, and discount stacking
- Test multi-step workflows for sequence bypass — can step 3 be reached without step 2?
- Test file upload functions for content-type bypass and malicious file execution
- Test account recovery and password reset flows for predictable tokens or race conditions
- Verify that deleted or deactivated accounts cannot be reactivated by manipulation
Tooling
Tools used by professionals
- Burp Suite Pro — primary intercept proxy for all request manipulation and manual testing
- OWASP ZAP — automated DAST scanning for OWASP Top 10, alongside manual testing
- SQLMap — SQL injection detection and exploitation
- Nikto — server misconfiguration, exposed files, outdated software
- Gobuster / Feroxbuster — discovery of hidden paths, backup files, admin panels
- JWT Tool — JSON Web Token testing for algorithm confusion and signature bypass
- Postman / Insomnia — API endpoint testing and request manipulation
Report requirements for web application testing
- Executive summary with overall risk rating and the three most critical findings
- Methodology section referencing OWASP Testing Guide v4.2 or equivalent
- Finding-by-finding technical documentation with CVSS score, affected URL, proof-of-concept, and remediation guidance
- Evidence of testing coverage — document all areas tested, not just findings
- Remediation priority matrix organised by severity
- Retest confirmation after remediation is complete
Infronest
Conclusion
Infronest's Web Application VAPT module manages the full engagement lifecycle from scoping through report delivery. Finding documentation, CVSS scoring, Burp Suite evidence upload, peer review workflows, and client-ready PDF report generation all operate in one tenant-isolated workspace.
Start a 14-day free trial at infronest.com — no credit card required.
Sources
- OWASP Testing Guide v4.2 and OWASP Top 10 2021
- IBM — Cost of a Data Breach Report 2025
- Verizon — Data Breach Investigations Report 2025
- PCI DSS v4.0 Requirement 11.4
Frequently Asked Questions
- How long does web application penetration testing take?
- A standard web application penetration test for a medium-complexity application takes 5 to 10 business days. A complex application with many API endpoints, multi-role access control, and extensive business logic may take 3 to 4 weeks. Reporting adds 3 to 5 days.
- What is the difference between DAST and web application penetration testing?
- DAST (Dynamic Application Security Testing) is automated scanning that runs against a live application. Web application penetration testing includes DAST but adds manual testing for business logic flaws, chained vulnerabilities, and contextual issues that automated tools cannot identify. DAST finds the obvious; manual testing finds the dangerous.
- How often should web application penetration testing be performed?
- Annual testing is the minimum. Best practice is to trigger a test after every significant code change, new feature release, or before a major customer or compliance audit. Organisations handling payment card data (PCI DSS) must test annually at minimum, and after any significant changes.