A web application penetration test is a manual, adversarial assessment of your application by people trying to break it. Scanners find known patterns. Testers find the flaws that need context: a user reading another tenant’s data, a checkout that accepts a negative quantity, or three low-severity issues that chain into an account takeover.
The OWASP Top 10:2025 is a reminder of where the risk sits. Broken access control is still first, now including server-side request forgery, and software supply chain failures entered the list at third. Neither shows up reliably in an automated scan.
Scoping decides the outcome
Most of the important decisions are made before anyone sends a request. Agree these in writing:
- What’s in scope. Domains, APIs, mobile or desktop clients that talk to the same backend, and third-party integrations you control. List what’s out of scope too.
- How much the testers know. In a grey-box test, testers get accounts and documentation. It finds more in the same time than a black-box test, where they start from nothing, and it’s the right default for most applications.
- Where testing happens. A staging environment that mirrors production lets testers try destructive cases safely. If production is the only option, agree which tests are off limits.
- When. A window long enough for the scope, avoiding releases and peak trading periods.
What to have ready
- Test accounts for every role, and at least two accounts per role in different tenants or organisations. Authorization testing is impossible with one account.
- API documentation, such as an OpenAPI file, a Postman collection or a GraphQL schema. Undocumented endpoints get less coverage.
- Test data that looks realistic: orders, invoices, files and users, so features behave as they do in production.
- A named contact on your side who can answer questions and unblock access during the test.
- Allowlisting, if your WAF, rate limiting or bot protection would otherwise block the testers. Decide whether you want to test those protections or what’s behind them.
- A heads-up to whoever watches alerts, so testing isn’t mistaken for an attack, or deliberately not, if you want to test detection.
During the test
Testers typically work through reconnaissance, authentication and session management, authorization between users and tenants, input handling and injection, business logic, client-side issues and the API layer.
Expect two kinds of communication. A critical finding, such as exposed customer data, should be reported to you immediately, not saved for the report. And if testing causes problems, such as account lockouts or a slow service, the testers should be reachable to pause or adjust.
The report and the fix
A good report gives management a short summary of risk and gives engineers what they need to reproduce and fix each finding. We’ve written about what a good penetration test report looks like and the red flags that mean you paid for a scan.
After the report:
- Fix root causes, not instances. If one endpoint is missing an ownership check, others probably are too.
- Retest. Have the testers confirm each fix, and record the result next to the finding.
- Look for patterns. A finding that recurs across tests points to a gap in design, review or tooling. That’s where the lasting improvement comes from.