Commissioning a web application penetration test for the first time - or for the first time with a new provider - comes with a reasonable set of questions. What will the testers actually do? What access do they need? How disruptive will it be? What should we expect in the report?
This guide answers those questions directly, without the marketing language that tends to obscure more than it clarifies.
What a Web Application Penetration Test Is
A web application penetration test is a structured security assessment of a web application. A team of security engineers attempts to identify vulnerabilities in the application - misconfigurations, logic flaws, authentication weaknesses, injection points, insecure APIs - and, where safe and agreed in advance, attempts to exploit those vulnerabilities to understand their real-world impact.
The goal is to give the application owner an accurate picture of the risk their application carries, with enough detail to address it.
This is different from a vulnerability scan. A scanner produces a list of potential findings based on signatures and version checks. A penetration test involves a human with experience and judgement who tests application logic, constructs multi-step attack chains, and examines how the application behaves under adversarial conditions that scanners cannot replicate.
Scope and Scoping Conversations
The most important work in a penetration test happens before testing begins: agreeing what is in scope.
Scope definition typically covers the specific URLs, API endpoints, and mobile or desktop client applications to be tested. It also covers test accounts - the credentials the testers will use during the engagement - and whether any functionality should be excluded (payment processors, third-party integrations, production data stores).
Grey-box versus black-box. Most modern application penetration tests are grey-box: the testers receive credentials and some documentation, but do not receive full source code access. Black-box testing (no credentials, no documentation, start from the login page) is slower and produces a different view of risk. Deciding which approach fits your objective is part of the scoping conversation.
Environment. Testing should be conducted in a staging or UAT environment that closely mirrors production. Testing directly against production carries operational risk and is typically reserved for specific, limited tests after a full staging-environment assessment. If a staging environment is not available or is not representative, discuss this with your provider before the engagement begins.
Test user accounts. Testers need accounts at different privilege levels to assess access control properly. This typically means at least one account per role type defined in the application. Creating these accounts in advance, with realistic (but synthetic) data, is one of the most important things you can do to ensure a thorough test.
What Happens During Testing
A well-run web application penetration test proceeds through several phases, though experienced testers do not execute these mechanically in sequence.
Reconnaissance and mapping. Testers enumerate the application's surface: pages, endpoints, parameters, API calls, client-side JavaScript, third-party integrations, and authentication mechanisms. This phase often reveals functionality that was not included in the initial documentation - API endpoints generated dynamically, admin panels accessible from unexpected paths, debug routes left exposed.
Authentication and session management. The authentication mechanism is assessed for weaknesses: account enumeration, weak lockout policies, insecure password reset flows, multi-factor authentication bypass vectors, session token predictability, and session fixation. For applications with OAuth or SAML integrations, these flows receive particular attention.
Authorisation testing. Access control is tested systematically. Can a low-privilege user access the resources of a high-privilege user by manipulating request parameters? Can an authenticated user in one tenant access data belonging to another tenant? Insecure Direct Object Reference and Broken Access Control vulnerabilities are among the most commonly exploited in real-world attacks and are often missed by automated scanners.
Input validation and injection. All user-controlled inputs - form fields, URL parameters, HTTP headers, JSON payloads - are tested for injection vulnerabilities: SQL injection, command injection, template injection, XML injection, and others. Modern frameworks have reduced the prevalence of classic SQL injection, but it remains present, particularly in applications with custom query construction or legacy code paths.
Business logic. This is where human judgement is most valuable. Testers look for ways to abuse the application's intended functionality: placing an order at a manipulated price, skipping required workflow steps, exploiting race conditions in financial transactions, or elevating account privileges through a sequence of individually-innocuous operations.
Client-side security. Cross-site scripting (XSS), DOM-based injection, insecure cross-origin resource sharing, subresource integrity, and Content Security Policy configuration are all assessed.
API security. RESTful and GraphQL APIs are tested with the same rigour as web interfaces. GraphQL schemas, in particular, often expose more of the data model than intended and warrant dedicated assessment.
Communication During the Engagement
Expect - and insist on - a communication channel that allows you to reach the lead tester during the engagement. This matters for two reasons.
First, if the testers encounter something that looks like a critical vulnerability with significant potential impact, they should notify you immediately rather than waiting for the final report. Early notification allows your team to begin remediation or take mitigating action while testing continues.
Second, if the testers cause unexpected disruption to the test environment - a condition that should be rare in a well-run engagement but can happen - you need a way to respond quickly.
The Report
A penetration test report has two primary audiences: the technical team who will do the remediation work, and management who need to understand the business risk. A good report serves both.
Executive summary. A two-to-three page section that describes the engagement, summarises the findings by severity, and provides an overall risk statement. This section should be comprehensible to a non-technical reader and should answer the question: "How exposed are we, and what should we prioritise?"
Technical findings. Each vulnerability is documented with: a description of the issue, evidence (typically a screenshot or HTTP request/response showing the finding), an assessment of impact and likelihood, and a concrete remediation recommendation. Findings are rated by severity - typically Critical, High, Medium, Low, and Informational.
Remediation guidance. Recommendations should be actionable. "Implement input validation" is not actionable. "Parameterise the SQL queries in the user search function at /api/users/search - the current implementation is vulnerable to SQL injection via the q parameter" is actionable.
After the Test: Remediation and Retesting
A penetration test report is the beginning of remediation work, not the end of the engagement. Development teams need to understand not just what the vulnerabilities are but why they occurred - whether they reflect a framework misconfiguration, a missing security control in the development process, or a specific code-level error.
Most engagements include a retest: after remediation work is complete, the tester verifies that the specific vulnerabilities identified have been resolved. This is distinct from a full re-assessment. If significant changes have been made to the application, a follow-on assessment may be warranted.
Treat the findings as data for your secure development lifecycle, not just a to-do list. Patterns in the findings - recurring input validation failures, consistent access control issues - point to process or training gaps that, if addressed, reduce the vulnerability surface in future development.