What it covers
Web application penetration testing is manual security testing of an application and its authenticated functionality, looking for flaws an attacker could exploit. Testing is normally aligned to the OWASP Web Security Testing Guide, which gives both parties a shared definition of coverage.
The categories that matter most in practice: broken access control between user roles, injection, authentication and session management, business logic flaws, insecure direct object references, sensitive data exposure, and server-side request forgery.
Why user roles drive the price
The most common scoping mistake is describing an application by page count or feature count. What actually drives testing effort is the number of distinct user roles, because every boundary between two roles is its own set of tests.
| Application | Roles | Access-control boundaries to test |
|---|---|---|
| Simple brochure app with login | 1 | Authenticated vs anonymous only |
| Typical B2B SaaS | 3 — admin, manager, user | Several, plus tenant isolation |
| Multi-tenant with delegated admin | 4+ | Many, and cross-tenant is critical |
Multi-tenancy deserves particular attention. The single highest-impact finding in a B2B SaaS pentest is usually cross-tenant data access — one customer able to reach another customer's records. Scanners essentially never find it; a tester with two accounts in two tenants finds it in an afternoon if it exists.
What testing actually involves
Reconnaissance and mapping. Enumerating the application, its endpoints and its technology stack.
Automated scanning. Efficient coverage of known CVEs, outdated components and misconfigurations.
Authentication and session testing. Login flows, password reset, MFA where present, session handling and fixation.
Authorisation testing. The heart of it — attempting to access data and functions across every role boundary, including by manipulating identifiers directly.
Input and injection testing. SQL, command, template and cross-site scripting.
Business logic testing. Completing workflows out of order, manipulating quantities and prices, bypassing intended sequences. Requires understanding what the app is for, which is why no tool does it.
Exploitation and chaining. Combining findings into a demonstrated attack path.
Grey-box beats black-box for most buyers
Black-box testing — no credentials, no documentation — feels like a more realistic simulation. For a fixed budget it usually finds less.
A real attacker has unlimited time for reconnaissance. You are paying by the day. Providing credentials for each user role and a brief architecture overview means the tester spends the engagement testing rather than discovering, and the authenticated functionality is where the serious findings live.
Black-box has a legitimate place when the question is specifically "what can an anonymous internet attacker reach". For "is our application secure", grey-box gives more per dollar.
What the report should show
Every finding with a severity, reproduction steps an engineer can follow, evidence of exploitation rather than just detection, and a remediation recommendation specific to your stack.
Plus an executive summary, a remediation priority order, and — the item most often missing — a retest letter after you have fixed things. See what a VAPT report should contain.
FAQs
What is web application penetration testing?
Manual security testing of a web application and its authenticated functionality, looking for flaws an attacker could exploit. It is normally aligned to the OWASP Web Security Testing Guide and covers access control, injection, authentication, business logic, insecure direct object references and data exposure.
How is web application pentest cost calculated?
Primarily by the number of distinct user roles rather than page or feature count, because every boundary between two roles is its own set of access control tests. Multi-tenancy adds further work since cross-tenant isolation must be tested explicitly. US market ranges run roughly $3,000 to $22,500.
What is the most serious finding in a SaaS pentest?
Usually cross-tenant data access — one customer able to reach another customer's records. Automated scanners essentially never find it because it requires two accounts in two tenants and an understanding of the data model, but a manual tester finds it quickly if it exists.
Should I choose black-box or grey-box testing?
Grey-box for most buyers. A real attacker has unlimited reconnaissance time while you are paying by the day, so providing credentials per role and an architecture overview means the tester spends the engagement testing the authenticated functionality where serious findings live. Black-box suits the narrower question of what an anonymous attacker can reach.
How long does a web application penetration test take?
Typically one to two weeks of testing plus around a week for reporting, for a single application with a few user roles. More roles, multi-tenancy or complex workflows extend it. Allow a further two to four weeks before retest so there is time to remediate.
Where to go next
See our penetration testing services, API testing, or what testing costs.