A web application penetration testing checklist covers three phases: preparation, active testing, and post-engagement remediation. Define scope, provide test accounts, notify your hosting provider, and sign rules of engagement before work begins. During testing, stay available to unblock the testing team. After testing, triage findings by severity, assign remediation owners, and schedule a retest.
Most delays and wasted effort happen at the preparation stage, when scope is vague, test accounts are missing, or the hosting provider has not been notified. Getting the groundwork right means your testing team spends their time finding vulnerabilities, not waiting for access.
What do you need to prepare before a web application penetration test?
The quality of a web application penetration test is determined largely before testing begins. Industry data consistently shows that scope ambiguity and missing access are the primary causes of wasted engagement time. The PTES (Penetration Testing Execution Standard) dedicates an entire phase to pre-engagement interactions for this reason: poor preparation does not just reduce coverage, it invalidates the exercise.
Work through the following before your testing provider begins:
Define scope precisely. List every domain, subdomain, API endpoint, and environment you want tested. Vague scope statements like "our main website" leave gaps and create disputes mid-engagement. If a system is out of scope, state that explicitly too.
Choose your testing type. Three options exist:
- Black box: The tester begins with no prior knowledge, simulating an unauthenticated external attacker. Reconnaissance consumes a significant portion of available testing days.
- Grey box: The tester receives test accounts, basic architecture documentation, and authentication flow details. This is the recommended approach for most commercial engagements: the same time investment produces significantly more exploitable findings because testers skip low-yield reconnaissance and focus on actual attack paths.
- White box: Full source code access and architecture documentation. The most thorough option and the best choice when you need to find every possible weakness, not just those reachable from the outside.
The counter-intuitive reality is that grey box testing more closely simulates how most real-world breaches happen. Attackers rarely begin with zero knowledge; they buy stolen credentials, conduct prior OSINT, or already have some form of access. Black box testing is technically "realistic" in the narrow sense of simulating an anonymous external attacker, but it underrepresents the threat model most organisations actually face.
Provision test accounts. Provide at least two accounts per user role: administrator, standard user, and read-only where applicable. Multiple accounts per role allow testers to check for horizontal privilege escalation, where one user accesses another user's data without authorisation. Missing test accounts is the single most common cause of incomplete coverage in web application tests.
Set up a staging environment. Testing on staging is strongly preferred. Production testing is possible but requires agreed testing windows (typically overnight or weekends) and a confirmed rollback plan with your hosting team. Discuss this during scoping, not on the morning testing begins.
Share documentation. Architecture diagrams, API documentation, user role definitions, and authentication flow descriptions all reduce wasted testing time. For API-heavy applications, providing an OpenAPI or Swagger specification can save a full day of endpoint enumeration. If your application has both a web front end and a backend API, a combined web application and API penetration test is the recommended approach.
Confirm rules of engagement. Document testing hours, out-of-scope systems, emergency contact numbers, and how inadvertently discovered sensitive data will be handled. This is not administrative overhead: it protects both parties and prevents genuine surprises when a tester triggers an alert.
Notify your hosting provider and internal security team. If your hosting provider or managed security team monitors for suspicious activity, they need advance warning. WAF (Web Application Firewall) blocks on the testing IP range will delay the engagement and may prevent entire areas of the attack surface from being tested. Whitelist the tester's IP range before day one.
Sign the statement of work and NDA. Testing should not begin without signed documentation confirming scope, liability, data handling, and confidentiality obligations. The February 2025 CREST Penetration Testing Accreditation Standard requires this explicitly as part of the Preparation domain.
[INSERT VISUAL: preparation-impact-diagram.svg]
Web application penetration testing scope checklist
| Item | Details to Provide | Why It Matters |
|---|---|---|
| Target URLs | All domains, subdomains, and explicit exclusions | Prevents scope disputes and missed coverage |
| API endpoints | REST or GraphQL endpoints, authentication methods | APIs are a common source of high-severity findings |
| Authentication method | SSO, OAuth, username/password, MFA configuration | Determines which authentication test cases apply |
| User roles | All roles with permissions defined | Required for privilege escalation testing |
| Test accounts | Minimum 2 per role (admin, standard user, read-only) | Enables horizontal privilege escalation testing |
| Hosting environment | Cloud provider, CDN, WAF vendor | Allows WAF whitelisting and provider notification |
| Third-party integrations | Payment processors, identity providers, embedded services | Sets scope boundaries and liability limits |
| Compliance requirements | PCI DSS, ISO 27001, SOC 2, GDPR mappings needed | Ensures findings map to relevant controls |
| Testing window | Permitted hours, production blackout periods | Avoids disruption to business operations |
| Documentation | Architecture diagrams, API specs, auth flow descriptions | Reduces reconnaissance time and increases exploitable findings |
What are the stages of a web application penetration test?
Two questions appear frequently on this topic: what are the 5 stages of penetration testing, and what are the 7 stages? Both reflect real methodology standards.
The PTES (Penetration Testing Execution Standard) defines 7 phases. CREST-accredited providers follow this framework with variations tailored to specific engagement types. OWASP's Web Security Testing Guide v4.2 (WSTG) organises test cases into 12 technical categories covering information gathering through to API testing. In practice, most clients experience 5 stages that map onto the PTES phases as follows:
[INSERT VISUAL: penetration-test-stages-timeline.svg]
Stage 1: Scoping and pre-engagement PTES phase: Pre-Engagement Interactions
The testing team confirms scope, rules of engagement, testing type, and access credentials. Legal documentation is signed. Test accounts are set up and verified. This stage determines everything that follows. Errors here, including ambiguous scope, unverified credentials, or missing out-of-scope definitions, compound throughout the engagement.
Stage 2: Reconnaissance and application mapping PTES phases: Intelligence Gathering and Threat Modelling
Testers map the application: crawling pages, identifying endpoints, enumerating parameters, and building a picture of the authentication and authorisation model. For grey box engagements with documentation provided, this phase is compressed significantly. For black box engagements, reconnaissance can consume 1 to 2 days of testing time before active exploitation begins. Threat modelling identifies which application areas represent the highest-value attack targets given the business context.
Stage 3: Vulnerability discovery PTES phase: Vulnerability Analysis
Automated scanning tools are combined with manual testing against the OWASP WSTG v4.2 test case library. Testers probe for injection flaws (SQL, NoSQL, command), broken authentication, insecure direct object references (IDOR), security misconfigurations, and logic errors that automated scanners routinely miss. The OWASP WSTG v4.2 covers 12 test categories; a thorough manual engagement works through all relevant categories for the application's technology stack.
Stage 4: Exploitation and post-exploitation PTES phases: Exploitation and Post-Exploitation
Confirmed vulnerabilities are exploited to establish real-world impact. This includes testing privilege escalation (vertical: gaining admin access from a standard user account; horizontal: accessing another user's data), data exfiltration paths, and chaining multiple lower-severity findings into a higher-impact attack sequence. Post-exploitation documents what an attacker could access or do following initial compromise: data accessible, persistence mechanisms available, and lateral movement paths within the application.
Stage 5: Reporting and debrief PTES phase: Reporting
Findings are documented with severity ratings (Critical, High, Medium, Low, Informational), reproduction steps, evidence, business impact descriptions, and specific remediation guidance. CREST standards require both executive-level and technical-level content. A debrief call follows delivery to walk through findings with technical and business stakeholders. For how to interpret the report your testing provider delivers, see our guide to reading a penetration testing report.
What happens during a web application penetration test?
Timeline
A standard web application penetration test runs 5 to 10 days of testing effort, depending on application complexity, the number of user roles, and the depth of API coverage. Complex applications with multiple integrations and hundreds of endpoints typically require 2 to 3 weeks. Your testing provider should give a clear estimate during scoping based on a walkthrough of the application, not a flat-rate assumption.
Communication
Most providers agree a communication channel (email, Slack, or Teams) for the testing period. Expect daily updates on progress, particularly if the tester encounters blockers or needs a test account reset. Responsive clients get more testing coverage: every hour spent waiting for a password reset or WAF whitelist update is an hour not spent finding vulnerabilities.
Severity escalation
Critical findings are not held for the final report. If a tester discovers SQL injection, authentication bypass, or remote code execution during the engagement, your point of contact is notified immediately. You can then decide whether to patch before testing continues or take the affected component offline. This is standard practice for CREST-accredited engagements.
Your team's role
Be available to answer questions. Test accounts may need resetting if lockout policies trigger. If a WAF or CDN rule blocks the testing IP range mid-engagement, your team will need to update the whitelist. Delays in responding to these blockers directly reduce effective testing time.
The cost of unpreparedness compounds during the engagement. A client who provides a staging environment, pre-configured test accounts, and an IP whitelist on day one enables a tester to begin exploitation within hours. A client who resolves those items across the first two days of a five-day engagement has effectively paid for a three-day test.
What should you do after a web application penetration test?
Review the report with your testing provider
Most providers include a debrief call as standard. Use it. Walking through findings with the tester gives your development and infrastructure teams the context needed to prioritise and fix issues correctly. The written report covers what was found; the debrief covers why it matters and how to approach remediation in practice.
Triage findings by severity
Research from BreachLock's 2024 Penetration Testing Intelligence Report found that only 48% of all pentest findings are ever remediated. Serious (Critical and High) findings fare better at a 69% resolution rate, but that still leaves nearly one in three critical vulnerabilities unaddressed. Use the following triage framework as a baseline:
- Critical and High: Remediate within 30 days
- Medium: Remediate within 90 days
- Low and Informational: Address in the next planned development cycle
The average time to remediate a critical application vulnerability is 74 days, according to 2025 industry data. Attackers can penetrate the average network in approximately 4 days. That gap is material.
Assign remediation owners
Each finding should have a named owner: a developer, an infrastructure engineer, or a third-party vendor if the issue sits in an integrated component. Unassigned findings do not get fixed. This is the primary reason findings remain open: not technical complexity, but accountability gaps.
Schedule a retest
Once remediation is complete, a retest confirms fixes are effective and no regressions have been introduced. Many providers include a retest window as part of the original engagement or offer it at a reduced rate. A finding marked "remediated" without independent verification is a finding that may still be exploitable.
Update your risk register
Record findings in your organisation's risk register, including those that have been remediated. This provides an audit trail for compliance frameworks and demonstrates due diligence to stakeholders, auditors, and insurers.
Feed findings into your SDLC
Use the report to improve your development process. Common findings (insecure session handling, missing security headers, input validation gaps) should become regression test cases and inform secure coding training. For context on which vulnerability categories appear most frequently in web application tests, see our guide to the OWASP Top 10 and what penetration testers look for.
Frequently asked questions
How long does a web application penetration test take?
A standard web application penetration test takes 5 to 10 days of testing effort. Smaller applications with limited endpoints and user roles sit at the lower end. Large or complex applications, particularly those with extensive APIs, multiple authentication flows, or embedded third-party functionality, typically require 2 to 3 weeks. Your testing provider should scope the engagement based on a walkthrough of the application, not a flat-rate assumption.
How often should you penetration test a web application?
Annually as a minimum. Most compliance frameworks (PCI DSS 4.0, ISO 27001:2022, SOC 2) require at least annual testing, and many mandate additional tests following significant changes. Commission a test after major architecture changes, new authentication systems, significant new feature releases, or following a security incident. Annual testing alone does not cover the risk introduced by continuous deployment cycles.
What is the difference between black box and grey box testing?
Black box testing means the tester begins with no prior knowledge of the application, simulating an unauthenticated external attacker. Grey box testing means the tester is provided with test accounts, documentation, and basic architecture information before work begins. Grey box produces more findings for the same time investment because testers spend less time on low-yield reconnaissance and more time on exploitation. For most commercial web application tests, grey box is the recommended approach. For a full breakdown of testing types and scope options, see our web application penetration testing service page.
Does a web application penetration test cover mobile apps and APIs?
It depends on how scope is defined. A web application penetration test typically covers browser-based interfaces and their underlying APIs. If your application has a mobile client that communicates with the same API, that API coverage may already be included. Mobile-specific testing (certificate pinning, local data storage, binary analysis) is a separate workstream. Confirm during scoping.