A web application penetration test is a manual, time-boxed attack on your application by a human tester, and its price is set almost entirely by scope: how many user roles, API endpoints and integrations the tester has to cover. Most manual web app tests in the US are quoted between $5,000 and $30,000. This guide sets out what a standard engagement covers, which scope items push the quote up, and what you need to hand testers before day one so you don’t pay for days lost to broken logins.
What a Web App Pentest Covers, Costs, and Needs From You
A manual web application penetration test usually costs $5,000 to $30,000 and takes 1 to 3 weeks, with complex multi-tenant SaaS platforms running past $50,000. The quote rises with each extra user role, API surface, tenant, and integration, and with add-ons such as source code review, out-of-hours testing, and attestation letters. Working test accounts for every role, API documentation, a stable staging environment, and allow-listed tester IPs are what keep the engagement on schedule.
Let Axipro help you build a business continuity plan that's practical, compliant, and audit-ready.
Schedule Your Free Assessment Today
What a Web Application Penetration Test Covers
A web application penetration test is a manual assessment in which a qualified tester attacks your application the way a real adversary would, then proves each finding with evidence. The tester works through the browser-facing application and the APIs it calls, before and after login, and chains small weaknesses into realistic attack paths. Most reputable providers structure the work around the OWASP Web Security Testing Guide and report against the OWASP Top 10, so findings map to what auditors and enterprise security reviewers expect.
The stakes are rising. Verizon’s 2026 Data Breach Investigations Report found that exploitation of vulnerabilities was the initial access vector in 31% of breaches, overtaking credential abuse for the first time in the report’s 19-year history. That dataset covers breaches between November 2024 and October 2025.
Web app pentest vs vulnerability scan
A vulnerability scan is an automated tool run that flags known issues, while a penetration test is a person confirming what an attacker could actually do. Scanners find missing headers, outdated libraries, and textbook injection points. They cannot tell that a standard user can read another customer’s invoices by changing an ID in the URL, because that request looks perfectly valid. A quote under $2,000 for a “web application pentest” is almost always a scan with a pentest label on the cover. The breakdown of automated vs manual penetration testing covers where each one fits.
Where web app testing ends and API, mobile and cloud testing begin
A web application pentest covers the web front end and the APIs that front end calls; mobile apps, cloud configuration and internal networks are separate engagements with separate quotes. If your iOS app talks to a different backend from your web app, that backend is not in scope just because it shares a login. Cloud findings such as an over-permissive IAM role or a public storage bucket belong to a cloud configuration review. Ask the provider to name these boundaries in the statement of work rather than assuming them.
What’s In Scope in a Standard Web Application Penetration Test
A standard web application penetration test covers the application before and after login, every user role you list, the APIs the front end depends on, and the business workflows that move money or data. The table shows what a complete engagement should test.
| Area | What the tester checks |
|---|---|
| Unauthenticated surface | Public pages, sign-up, login, password reset, exposed files and directories |
| Authentication and sessions | MFA bypass, password reset flaws, session fixation, token expiry, cookie flags |
| Authorization across roles | Horizontal access (user A reads user B’s data), vertical access (user to admin), IDOR |
| Input handling | SQL, command and template injection, cross-site scripting, SSRF, file upload abuse |
| Business logic | Skipped workflow steps, negative quantities, coupon reuse, race conditions on payments |
| APIs the app calls | REST or GraphQL endpoints behind the UI, object-level authorization, mass assignment, rate limits |
| Admin panels and integrations | Admin functions, webhooks, SSO flows, third-party callbacks |
| Configuration | Security headers, TLS, CORS, verbose errors, exposed debug endpoints |
Authorization testing across roles is where the highest-severity findings usually sit. The OWASP Top 10:2025 keeps Broken Access Control at number one, and OWASP reports that 100% of the applications tested had some form of it across the 40 weaknesses mapped to that category. A test that covers only one authenticated role cannot find most of these, because the flaw only appears when a lower-privileged account requests something a higher-privileged account owns.
API-heavy applications get a second checklist. Testers use the OWASP API Security Top 10 (2023) alongside the web Top 10, and it ranks Broken Object Level Authorization first. Undocumented and legacy API versions that are still reachable deserve the same attention as the current ones, since nobody has been maintaining them.
What’s Usually Out of Scope Unless You Ask
Denial-of-service testing, social engineering, third-party services you don’t own, and production databases are excluded from a standard web application pentest unless the statement of work adds them. Anything not listed as in scope should be treated as out of scope, by you and by the tester.
Third-party and SaaS components need their owner’s permission. Your payment processor, identity provider or embedded chat widget belongs to someone else, and testing it without approval can breach their terms. Major cloud providers publish penetration testing policies that list what customers may test without asking; anything outside those policies needs the provider’s sign-off.
Denial-of-service and load testing stay out because they risk taking down the service you are paying to protect. If you need to know how the application behaves under load, buy a separate load or resilience test with its own window. Testers will still report missing rate limits, because that is an access control and abuse issue rather than a stress test.
Social engineering and phishing test your people, not your code, and are scoped as a separate engagement. Production databases and fragile systems are usually excluded or tested under strict rules of engagement that ban destructive actions, which is why most web app tests run against a staging environment that mirrors production.
How Web Application Penetration Testing Is Priced
Web application penetration testing is priced by tester days, and tester days are driven by scope: the number of user roles, pages that accept input, API endpoints, and integrations. Published pricing from US providers in 2025 and 2026 puts most manual web app tests between $5,000 and $30,000, with complex platforms well above that.
| Application profile | Typical scope | Typical price (USD) |
|---|---|---|
| Simple web app | 1 to 2 user roles, a handful of forms, small API | $5,000 to $10,000 |
| Mid-size SaaS | 3 to 5 roles, REST or GraphQL API, a few integrations | $10,000 to $20,000 |
| Complex or multi-tenant platform | Many roles and tenants, admin portal, SSO, microservices | $20,000 to $50,000+ |
Axipro is a compliance readiness and cybersecurity consultancy and Drata Elite Partner that helps SaaS and technology companies get audit-ready for SOC 2, ISO 27001, ISO 42001 and other frameworks, and it runs CREST-certified web application penetration testing as part of that work. Axipro’s web application tests start from $500.
“A web app pentest quote is really a quote for tester days, and the days come from roles, API endpoints and integrations, not page count. When two quotes for the same app differ by three times, one of them has usually left the admin role or the API out of scope,“ says Ali Hayat, CEO of Axipro.
Page count is a weak proxy for effort. A 20-page app with four roles and a payments flow takes longer to test well than a 200-page content site with one login. For a SOC 2-specific budget, the guide to SOC 2 penetration testing cost breaks the numbers down by company stage.
The price of skipping the test is larger. IBM’s 2026 Cost of a Data Breach Report puts the average US breach at $11.5 million, against a global average of $4.99 million, and lists offensive security testing among the factors that most reduced breach costs.
Pro Tip: Ask every provider
Ask every provider to state the number of tester days in the quote. Two quotes at the same price can hide a 3-day test and a 10-day test, and the day count is the only way to compare them.
What Costs Extra in a Web Application Pentest
Extra user roles, multi-tenant isolation testing, deep API coverage, separate mobile backends, black-box testing, source code review, retesting, rush scheduling, and attestation letters are the items most likely to push a web application pentest quote above its base price. Each one adds tester days or reporting work, and each is worth paying for in some situations and not others.
| Add-on | Why it costs more | When it’s worth it |
|---|---|---|
| Additional user roles | Each role is checked against every other role for horizontal and vertical access | Apps with admin, manager and customer tiers |
| Multi-tenant isolation | Role tests are repeated across at least two tenants to catch cross-tenant data leaks | B2B SaaS where customers share infrastructure |
| Deep API testing | Endpoint-by-endpoint testing beyond what the UI calls, including legacy versions | API-first products and public APIs |
| Mobile front end on its own backend | A different API surface, plus analysis of the app binary | Mobile apps that call separate services |
| Black-box testing | Days go on reconnaissance instead of testing, so coverage costs more | Simulating an outside attacker; rarely the best use of a compliance budget |
| Source code review | A reviewer reads the code alongside dynamic testing | Complex authorization logic, custom crypto, secure development evidence |
| Retesting | A second pass to verify each fix | Always, if the report is audit evidence |
| Rush or out-of-hours testing | Night or weekend windows and short-notice staffing | Production-only environments or a hard deal deadline |
| Attestation letter or compliance-mapped report | Extra reporting written for auditors or customers | SOC 2, PCI DSS and enterprise security reviews |
Multi-tenant testing is the add-on buyers underestimate most. It often doubles the role count, because every role is tested inside its own tenant and then against a second tenant. For a B2B SaaS product, a cross-tenant leak is the finding an enterprise customer cares about most, so cutting this to save budget is usually a false economy.
Important: Check retesting first. PCI DSS v4.0.1 Requirement 11.4.4 requires exploitable findings to be corrected and the test repeated to verify the fix, and SOC 2 auditors look for the same closure evidence. A quote without a retest is not a cheaper version of the same deliverable.
Axipro retests every closed finding as part of its engagements, so the final report shows each issue as fixed and verified rather than only found.
What Testers Need From You Before Testing Starts
Testers need working accounts for every in-scope role, API documentation, a stable test environment with realistic data, allow-listed source IPs, signed rules of engagement, and a named emergency contact before day one. Each item missing on the first morning turns into paid tester hours spent waiting, or a test that covers less than the statement of work promised.
On Axipro engagements, the two most common causes of lost testing days are broken test accounts and blocked tester traffic.
The accounts either don’t work on day one, or they exist but lack the right role and any realistic data to work with. Separately, the web application firewall or rate limiting blocks the tester’s IPs within the first hour because nobody allow-listed them. Both problems are cheap to prevent and expensive to discover on the morning of kickoff.
Work through this list in the week before testing starts:
- Scope inventory. Production and staging URLs, subdomains, user roles, integrations, and anything explicitly excluded.
- Test accounts for every role and tenant. Two accounts per role, so testers can attack one from the other, in at least two tenants for multi-tenant apps. Set up MFA on them, or document an approved bypass for test accounts.
- Realistic data. Populated records, invoices, files and workflows, so business logic can be exercised. An empty account has nothing to steal.
- API documentation. An OpenAPI (Swagger) file, GraphQL schema or Postman collection, including older versions that are still live.
- Architecture and data flow diagram. One page showing where data goes, which third parties receive it and where authentication happens.
- Allow-listing. Tester source IPs added to the WAF, CDN bot protection and rate limiting, or a dedicated testing hostname that bypasses them.
- Rules of engagement. Testing windows, banned actions (denial of service, data deletion, emails to real customers) and the escalation path for critical findings.
- Emergency contact. Someone who answers the phone during the testing window and can restart a service.
- Third-party permissions. Written approval from any hosting provider or SaaS vendor whose testing policy requires it.
- Source code access. Repository read access, for white-box or code-assisted tests only.
Pro Tip: Test every account
Test every account the day before kickoff: log in, switch roles and complete one key workflow in each. Ten minutes of checking saves a day of rescheduling.
A staging environment only helps if it matches production. Testing an outdated staging build produces findings that may not exist in production and misses ones that do. Deploy the current release to staging before kickoff, and freeze deployments there for the testing window so findings stay reproducible.
Axipro’s free Pentest Scope Builder turns the scope inventory above into a scoping document you can share with providers before you ask for quotes.
What Happens During and After a Web Application Penetration Test
A web application penetration test runs in four stages: scoping and rules of engagement, active testing, reporting, and retesting after you fix the findings. At Axipro, scoping and the statement of work take 2 to 3 business days, and a web application test runs 5 to 15 business days depending on scope. Axipro’s methodology follows the Penetration Testing Execution Standard (PTES), and a tester manually validates every finding before it reaches the report.
Black-box, grey-box or white-box approach
Grey-box testing, where the tester gets user credentials but not source code, is the most common choice for SaaS applications because it spends tester days on the authenticated application where the serious flaws live. Black-box testing simulates an outsider with no access and burns time on reconnaissance. White-box testing adds source code and architecture access, which finds root causes faster but costs more. Axipro’s greybox pentest for Substrata shows what that approach looks like on a live product.
What the web app pentest report should contain
A web application pentest report should contain an executive summary, a scope and methodology statement, and individual findings with reproduction steps, proof-of-concept evidence, a CVSS severity score, and remediation guidance a developer can act on. A retest section then records which findings were fixed and verified. A report with no reproduction steps and no proof of concept is scanner output, whatever the cover says. The guide to what a VAPT report includes walks through each section in detail.
How Web App Pentests Support SOC 2, ISO 27001, PCI DSS and HIPAA
A web application penetration test is the evidence most auditors and enterprise customers expect for application security, even where a framework doesn’t name a pentest outright. What each framework asks for differs:
| Framework | What it asks for |
|---|---|
| PCI DSS v4.0.1 | Requirement 11.4 requires penetration testing at least once every 12 months and after significant change, with application-layer testing in the methodology and a retest of fixed findings (11.4.4) |
| ISO/IEC 27001:2022 | Annex A 8.29 covers security testing in development and acceptance, and 8.8 covers management of technical vulnerabilities; a pentest is the usual evidence for both |
| SOC 2 | No explicit pentest requirement, but auditors routinely expect one as evidence for monitoring and vulnerability management criteria |
| HIPAA | The Security Rule requires regular technical evaluation; HHS proposed an explicit 12-month pentest requirement in January 2025, which had not been finalized as of late 2026 |
According to the PCI Security Standards Council’s document library, the full text of Requirement 11.4 sits in PCI DSS v4.0.1, and NIST’s SP 800-115 Technical Guide to Information Security Testing and Assessment is the methodology reference many testers cite to satisfy it. For SOC 2 specifically, what auditors expect from a SOC 2 penetration test covers Type I and Type II expectations.
How to Compare Web Application Pentest Quotes
Compare web application pentest quotes on tester days, roles and endpoints in scope, retest terms and report contents, not on the headline price. Before you sign a statement of work, get written answers to these questions:
- How many tester days does the quote include?
- Which user roles are in scope, and how many accounts per role will the tester use?
- Which APIs are in scope, and roughly how many endpoints?
- Is retesting included, and how long after the report can you request it?
- Who will do the testing, and what certifications do they hold (OSCP, OSWE, CREST)?
- Can you see a redacted sample report?
- Will critical findings be reported during testing, or only at the end?
Axipro delivers findings as a PDF and machine-readable report, retests closed findings, and issues a final attestation that can be shared with auditors and enterprise customers.
Worth Knowing: Individual certifications
Individual certifications such as OSCP and OSWE tell you about the tester. CREST accreditation tells you about the company: its methodology, staff vetting and quality processes have been assessed by an international accreditation body for the security testing industry.
Scoping a Web Application Pentest Without Overpaying
A web application penetration test is worth what its scope covers, so the cheapest way to get value is to scope it accurately and prepare for it well. List every role, tenant and API up front, confirm retesting is included, and hand testers working accounts, documentation and allow-listed access before day one. Do that, and most manual web app tests land in the $5,000 to $30,000 range with no days lost to setup.
Frequently Asked Questions
How much does a web application penetration test cost?
A manual web application penetration test costs $5,000 to $30,000 for most applications, based on published US pricing in 2025 and 2026. Simple apps with one or two roles sit at the lower end, mid-size SaaS products land around $10,000 to $20,000, and complex multi-tenant platforms can exceed $50,000. Quotes under $2,000 are usually automated scans.
How long does a web application penetration test take?
A web application penetration test takes 1 to 3 weeks of active testing for most applications, plus a few days for scoping and reporting. At Axipro, a web application test runs 5 to 15 business days depending on the number of roles, endpoints and integrations in scope.
Is API testing included in a web application penetration test?
A web application penetration test usually includes the APIs the web front end calls, but not every endpoint the API exposes. Undocumented endpoints, legacy versions and APIs used only by mobile apps or partners often need a separate API penetration test. Ask the provider to list the API scope in the statement of work.
Is retesting included in the price of a web app pentest?
Retesting is included by some providers and billed separately by others, so check the statement of work. Retest evidence matters for compliance: PCI DSS v4.0.1 Requirement 11.4.4 requires fixed findings to be retested, and SOC 2 auditors look for the same proof that issues were closed.
Does a web application pentest satisfy SOC 2 and ISO 27001?
A manual web application pentest with a full report and retest is the evidence SOC 2 auditors and ISO 27001 certification bodies most commonly accept for application security testing. SOC 2 does not mandate a pentest, but auditors routinely expect one. ISO/IEC 27001:2022 Annex A controls 8.8 and 8.29 are usually evidenced with pentest results.
