Web application penetration testing: what we test and prove

If your web application holds customer data or money, you need to know what a determined user could do to it before a customer or an attacker finds out. Web application penetration testing answers with proof, not a list of scanner warnings.

What do we test in a web application?#

We test the places where web apps fail in practice. OWASP Top 10:2025 ranks Broken Access Control first, so most of our effort goes to who can do what. The OWASP Web Security Testing Guide gives us the test structure.

We test with direct HTTP requests, and with Chromium for issues that need a real browser. We also review client-side JavaScript bundles and compare what an anonymous caller and a signed-in caller can do.

Black box or grey box?#

In a black-box test we start as an outsider with no accounts. In a grey-box test you give us accounts, roles and documentation. We recommend grey box for most apps, because the access-control questions above need at least two accounts. Read black, grey and white box testing if you are unsure.

How do we prove a finding?#

A finding needs evidence of a real effect. A write is proven by reading the changed record back through another session. A bare "success" response is not proof. The methodology page states the full standard.

We run controls next to each exploit request: a nonexistent identifier, a wrong record type, another account's token, an anonymous request. If the control behaves like the exploit, we have not found a flaw. Controls that held are listed in the report, so a fix does not break a working protection.

We label evidence. "Observed" means we reproduced it. "Browser-observed" means we showed it in a real browser. Inferred paths are labeled separately. Open questions go in a "Limitations and open questions" section, not into confirmed impact.

GET /api/notes/7731 HTTP/1.1
Host: app.example.com
Cookie: session=<user-A-session>

HTTP/1.1 200 OK
Content-Type: application/json

{"id":7731,"owner":"b@example.com","title":"Q4 plan"}

What do you get?#

You get a written report in HTML, PDF and Markdown, plus proof-of-concept scripts. It has an executive summary with priority actions, a findings-at-a-glance table, and one section per finding with description, impact, verified results, reproduction steps and remediation. Severity uses four levels: Critical, High, Medium and Low, each with a written definition. We do not add CVSS vectors by default. Tell us at scoping if your program needs them.

After you fix findings, we can retest them. See retesting. The sample report shows the layout.

What do we need from you?#

• Written authorization from the system owner.
• The URLs and environments in scope, and anything out of scope.
• Two or more test accounts per role, owned by you and marked as test data.
• API documentation, a collection or a route list, if you have one.
• A technical contact who can answer questions during the test.
• Notes on rate limits, WAF rules or alerts that may trigger.

The guide on how to prepare for a penetration test has a longer checklist.

What changes the quote?#

The price follows scope. The main drivers are the number of roles, the number of distinct features and API routes, the environment (staging or production), whether you want grey-box access, and whether you need a retest. We publish no prices and quote after a short call and a written scope (see pricing for what a quote includes).

Excession Labs also runs AI-assisted testing for web apps and APIs with Incursion. AI Pentest Services describes that method.

Ready to scope a test? Request a pentest or ask about the free pentest pilot.