In the OWASP Top 10:2025, A01 Broken Access Control holds the number one position, mapping 40 CWEs, and OWASP records that 100 percent of applications in its contributed dataset were found to have some form of broken access control, with more than 1.8 million occurrences. Those are precisely the flaws a web application penetration testing engagement exists to find, and precisely the flaws an automated scanner cannot reason about, because deciding whether user A should be allowed to read user B's invoice requires knowing your permission model, not just your HTTP responses.
This post is written for the team buying a test this quarter, usually because an enterprise customer's security review demanded a report, a SOC 2 or PCI cycle came around, or a major release is about to ship. It covers what belongs in scope, what the tester actually does, what comes back, what it costs, and what you have to prepare. Read it and you should be able to draft your own scope document. Stingrai delivers this work through its web application penetration testing service.
What web application penetration testing actually covers
The mistake that produces a weak report is scoping the application as a website. An application is a permission model with a user interface attached, and most of its risk sits behind the login form. Write scope as three columns and the arguments disappear.
In scope by default | In scope only if agreed in writing | Explicitly out of scope |
|---|---|---|
Unauthenticated surface: registration, login, password reset, public pages, error handling | Payment and money-movement paths executed end to end in a sandbox | Denial of service, load and stress testing, resource exhaustion |
Authenticated surface for every supplied role, including admin and support consoles | Destructive actions such as account deletion or bulk state changes | Destructive exploitation, data deletion, production configuration changes |
APIs behind the application, including endpoints the interface never calls | Testing against production rather than a staging environment | Third-party SaaS and payment processors you do not own |
Authentication, session management, multi-factor enrolment and recovery flows | Source code review and architecture review, which is the white-box add-on | Social engineering of your staff or your customers |
Authorization at object and function level, across every role pair | Sustained brute force or credential-stuffing simulation | Physical entry and the underlying cloud provider's infrastructure |
Tenant boundaries in multi-tenant applications, including cross-organization access | Testing outside the agreed window or from undeclared source addresses | Bulk exfiltration beyond proof-of-access samples |
File upload, download, parsing and storage paths | Mobile clients and desktop clients that consume the same API | Any asset you cannot lawfully authorize testing against |
Business logic: workflow sequencing, limits, discounts, quotas, approvals | Chained exploitation that pivots into cloud or internal infrastructure | Findings in dependencies with no reachable path in your app |
Two boundaries cause most disputes, so settle them in writing.
APIs are part of the application, not a separate product. The interface exercises a fraction of what the backend exposes. Endpoints built for a deprecated screen, an internal tool or a partner integration still answer requests. If the scope says "the web app" and the vendor never asks for an OpenAPI specification or a request collection, they are testing the parts of your API a browser happens to call. The classes that hide there are catalogued in the OWASP API Security Top 10 (2023), led by API1:2023 Broken Object Level Authorization and API5:2023 Broken Function Level Authorization.
Infrastructure under the app is a different engagement. The host operating system, the network perimeter, the identity directory and the internal network are covered by external network penetration testing and internal network work, not by an application test. Scope both when your application sits on infrastructure you manage.
Why role coverage drives web application penetration testing scope and price
Authorization testing does not scale with the number of pages. It scales with the number of directional actor pairs, because for every pair the tester has to ask whether the first actor can reach objects and functions belonging to the second. Add the unauthenticated visitor as an actor, because forced browsing to authenticated endpoints is a real finding.
Authenticated roles | Actor contexts including anonymous | Directional authorization checks | Doubled for a second tenant |
|---|---|---|---|
2 (user, admin) | 3 | 6 | 12 |
3 (user, manager, admin) | 4 | 12 | 24 |
5 (plus support, billing) | 6 | 30 | 60 |
8 (plus auditor, API client, partner) | 9 | 72 | 144 |
Each of those checks then multiplies by the number of sensitive object classes and privileged functions in the app. A platform with eight roles, two tenants and thirty object types is not four times the work of a two-role app; it is closer to an order of magnitude. This is why an honest quote asks how many roles you have before it asks how many pages.
A second detail decides whether the work is possible at all. Testing horizontal authorization, where a user reaches another user's data at the same privilege level, requires two accounts in the same role. One account per role only permits vertical testing, where a low-privilege user reaches admin functions. Provision two accounts for every role, and in multi-tenant applications provision them in two separate tenants with realistic, distinguishable data.
Black-box, grey-box and white-box, and which returns most per dollar
These are not tiers of quality. They are different starting positions, and each buys a different distribution of findings.
Dimension | Black-box | Grey-box | White-box |
|---|---|---|---|
Tester starts with | A URL and nothing else | Credentials for every role, API documentation, a walkthrough | Everything above, plus source code and architecture documents |
Budget spent on discovery | High, often a third of the engagement | Low | Lowest |
Authorization coverage | Weak, limited to what can be inferred | Strong across supplied roles | Strongest, including code paths with no interface |
Business logic findings | Rare | Common | Common, with root cause identified |
Finds issues in code that has not shipped | No | No | Yes |
Best used for | Proving what an anonymous attacker sees | Most engagements, most of the time | Payment flows, complex permission models, regulated data |
Coverage per dollar | Lowest | Highest | High, at higher total cost |
Grey-box wins for most buyers because the budget goes into permission logic rather than reconnaissance. Real attackers register an account or buy one, so starting the tester without credentials does not simulate a real adversary; it simulates an adversary in their first hour. Stingrai's web application security practice aligns testing with the OWASP Web Security Testing Guide, the OWASP Application Security Verification Standard, PTES and NIST SP 800-115, and those standards are worth naming directly in your scope document so both sides agree on coverage.
The finding classes that matter, and the ones scanners systematically miss
A useful report clusters into a predictable set of classes. The right-hand column is the one to read before buying an automated-only option.
Finding class | What it looks like in your application | Found reliably by an unassisted scanner |
|---|---|---|
Broken object-level authorization (IDOR) | Changing an identifier in a request or API path returns another customer's record, invoice or file | No, the tool cannot know whose record it should be |
Broken function-level authorization | A standard user reaches an administrative action because the check lives in the interface, not the server | No |
Broken object property-level authorization | A user submits extra fields and updates attributes they should not control, such as role or account balance | No |
Tenant isolation failure | A request scoped to one organization returns or writes data belonging to another | No |
Business logic abuse | Discounts stacked past policy, quotas bypassed, refunds exceeding payment, approvals skipped | No, the tool has no concept of your business rules |
Broken workflow sequencing | A multi-step process such as checkout, onboarding or KYC completes with steps skipped or replayed | No |
Race conditions | The same coupon, withdrawal or invitation is redeemed twice when requests arrive concurrently | No |
Server-side request forgery | The application fetches a URL you supply, reaching internal services or cloud metadata endpoints | Partially, and often only the naive variants |
Injection | SQL, NoSQL, command, template or LDAP input reaching an interpreter without separation | Often, this is scanner home ground |
Authentication and session weaknesses | Weak reset tokens, sessions surviving logout or password change, multi-factor enrolment bypass, tokens with excessive lifetime | Partially |
File upload and file handling | Content-type checks bypassed, path traversal on storage, unauthenticated retrieval of other tenants' documents | Partially |
Security misconfiguration and exposure | Debug endpoints, verbose errors, permissive CORS, secrets in client bundles | Often |
Three points of precision matter when you write these into a scope document. Broken object-level authorization is the modern name for what most engineers still call IDOR, and in A01:2025 Broken Access Control it sits alongside forced browsing, metadata manipulation and, in the 2025 revision, server-side request forgery as a notable CWE. Business logic abuse has no signature to match, which is why the OWASP list treats insecure design as its own category. And race conditions are a scheduling problem rather than an input problem, so they are invisible to any tool that sends one request at a time.
The gap between what a scanner returns and what an authorization-aware test returns is the whole argument for buying a real engagement, and it is examined in detail in why API scanners miss BOLA and IDOR.
What the tester actually does, phase by phase
Below is the shape of a mid-sized engagement on a multi-tenant SaaS product. Calendar time runs longer than tester days because of provisioning and report review.
Phase | What happens | What you receive |
|---|---|---|
Kickoff | Rules of engagement signed, environment confirmed, roles enumerated, escalation path agreed, source addresses declared | Signed authorization, tester source addresses, agreed exclusions |
Mapping | Application walkthrough, route and endpoint enumeration, API specification reconciled against live behaviour, role-to-function matrix built | Endpoint inventory and role matrix, including endpoints not in your documentation |
Authentication and session | Registration, login, reset, multi-factor enrolment and recovery, session lifecycle, token handling | Early notice of any authentication bypass |
Authorization | Every directional role pair against every sensitive object and function, plus cross-tenant checks | Confirmed authorization findings with request evidence |
Business logic | Workflow sequencing, limits, pricing and discount rules, quotas, approval chains, concurrency behaviour | Logic findings tied to business impact in your terms |
Input and data handling | Injection classes, file handling, server-side request forgery, deserialization, output encoding | Validated technical findings, false positives removed |
Chaining and impact | Combining findings into a path that proves real consequence, with evidence capture | Attack narrative and proof-of-concept package |
Reporting and debrief | Severity with business context, remediation guidance, quality review, technical and executive walkthrough | Final report, machine-readable export, live readout |
Two behaviours separate a serious provider from a report factory. Critical findings reach your escalation contact within hours of validation rather than in a document three weeks later. And every finding carries request and response evidence produced by the tester, not a plugin identifier inherited from a scanner.
Where Snipe fits, and where senior testers take over
Stingrai's Snipe is an autonomous agent built specifically for web application testing. It performs black-box dynamic testing and white-box source review, opens AutoFix pull requests against the code that caused a finding, and runs as a pull-request gate that blocks vulnerable code from merging. It was trained on public HackerOne disclosure data and human pentester tradecraft, and it is aimed at the complex classes above, including broken object-level authorization, broken function-level authorization and business logic abuse, rather than only the configuration floor.
Being honest about the boundary is more useful than overselling it.
Capability | Autonomous | Hybrid | Enterprise |
|---|---|---|---|
Continuous black-box and white-box coverage of one web app plus its APIs | Yes | Yes | Yes |
AutoFix pull requests and pull-request gating | Yes | Yes | Yes |
Automated retests after each fix | Yes | Yes | Yes |
Human validation of every finding by certified testers | No | Yes | Yes |
Manual testing, vulnerability chaining and novel logic abuse | No | Yes | Yes |
PTaaS portal with Jira and Slack integration, quarterly executive reports | No | Yes | Yes |
Network, wireless, physical and social engineering modules | No | No | Yes |
No High or Critical Finding = Don't Pay guarantee | Yes | Yes | Not applicable |
The dividing line is judgement. An agent is excellent at breadth, at repeating the full authorization matrix on every release, and at catching regressions the day they merge. A senior tester is what you want for abuse cases specific to your commercial model, for chaining three medium findings into one critical, and for arguing severity in terms of your contracts. That is the reasoning behind the Hybrid tier, and the split is developed further in autonomous versus human pentesting scope.
What the deliverable contains
A report that satisfies an engineer, an auditor and an enterprise customer at the same time has eight components.
Executive summary. Business risk in plain language, the two or three paths that matter, and posture relative to the last test. No score tables here.
Attack narrative. The engagement in sequence, showing how a low-privilege account became a cross-tenant data exposure.
Coverage statement. Roles tested, environment, endpoint inventory, what was excluded and why. This is the section your customer's security reviewer reads first.
Findings register. Per finding: identifier, affected endpoints and roles, a standard severity plus a business-context rating, request and response evidence, reproduction steps, and remediation at code level.
Remediation plan. Sequenced by risk reduced per unit of engineering effort, not by severity alone, with systemic fixes separated from one-off patches.
Retest appendix. Updated status per finding once fixes are verified.
Machine-readable export. CSV or JSON so findings reach your issue tracker without retyping.
Completion letter. A short, shareable summary without exploit detail, for customers and underwriters. The difference is covered in completion letter versus full report.
Web application penetration testing supports your SOC 2, ISO 27001 and PCI DSS programs by producing the technical evidence those programs reference. Be precise about what is actually mandated. PCI DSS v4.0.1 is the one framework here that mandates penetration testing across a general population, and CMMC requires it at Level 3 only. ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate it in that way, and ISO 27001 and SOC 2 set no frequency, so an annual cadence there is driven by auditors, customers and insurers. In SOC 2, vulnerability scanning maps to CC7.1 while a penetration test lands at CC4.1. In ISO 27001:2022, cite Annex A 8.8 and A 8.29; A.12.6.1 belongs to the withdrawn 2013 numbering and should not appear in a 2026 scope document.
Duration and the real web app pentest cost drivers
Cost is driven by the permission model and the workflow count, not by page count or by how many megabytes your front end ships.
Cost driver | Why it moves the price | What to give the vendor |
|---|---|---|
Number of distinct roles | Authorization work scales with directional role pairs, the largest single factor | A role list with what each role can do |
Multi-tenancy | Every check runs again across a tenant boundary, roughly doubling authorization effort | Whether tenants share a database, and how isolation is enforced |
API endpoint count and documentation quality | Undocumented endpoints have to be discovered before they can be tested | An OpenAPI specification or request collection, plus known deprecated routes |
Money movement and regulated data | Payment, payout, refund and settlement paths need careful, sandboxed handling | Which flows move money, and where the sandbox lives |
Workflow complexity | Multi-step processes with approvals and state machines are where logic abuse hides | A list of your ten most business-critical workflows |
Source code access | White-box review adds effort and finds root causes and unreachable-by-interface code | Repository access and a build or architecture overview |
Environment quality | Testing a staging environment that lags production produces findings nobody can reproduce | Confirmation of parity, or a decision to test production with guardrails |
Integrations | Single sign-on, OAuth connected apps, webhooks and partner callbacks each add surface | An inventory of every integration and the scopes it holds |
Retest and cadence | One retest window differs from continuous testing on every release | Your remediation timeline and release frequency |
Evidence requirements | Customer questionnaires and auditor-grade packs add reporting effort | The frameworks and questionnaires you must satisfy |
As a planning shape rather than a price list: a single-tenant application with two roles and fewer than thirty endpoints is typically a few tester days across one to two weeks elapsed; a multi-tenant SaaS product with four to six roles and a few hundred endpoints is one to two tester weeks across two to four weeks; a platform with eight or more roles, money movement and several integrations runs longer and usually benefits from white-box access.
Stingrai publishes web application pricing rather than hiding it behind a call. Autonomous is US$3,000 one time or US$450 per month, and Hybrid is US$6,800 one time or US$1,275 per month, both on a twelve-month engagement covering one web application plus its APIs. Enterprise is scoped to your attack surface and quoted individually. The No High or Critical Finding = Don't Pay guarantee applies to the Autonomous and Hybrid tiers. Current packages sit on the Stingrai pricing page, and scoping runs through the web application penetration testing service. If you are normalizing competing proposals, how to compare penetration testing quotes sets out a method.
What to prepare, retesting, and how to spot a scan with a cover page
Preparation is the difference between testing starting on day one and starting on day four.
Item | What to have ready | Why it matters |
|---|---|---|
Written authorization | Signed by someone with authority over the application, naming environments and the window | Testing cannot begin without it, and your hosting provider may need notice |
Credentials for every role | Two accounts per role, in two tenants where multi-tenant, with multi-factor pre-enrolled | Without a second same-role account, horizontal authorization cannot be tested |
Seeded test data | Distinguishable records per account, so cross-account access is unambiguous in evidence | Prevents arguments about whether a finding is real |
API documentation | OpenAPI specification or request collection, plus a list of deprecated and internal endpoints | Undiscovered endpoints are untested endpoints |
Environment decision | Staging with production parity, or production with agreed guardrails | A stale staging environment produces findings you cannot reproduce |
Rate limit and WAF allowances | Whether tester addresses are allowlisted, and whether lockout thresholds are relaxed | Blocking can silently hide vulnerable functionality behind a filtered response |
Contacts and escalation | Technical contact, out-of-hours number, and who receives a critical finding | Criticals need a human within hours |
Release calendar | Freezes, deploys and migrations during the window | An application that shifts mid-test yields irreproducible findings |
Reset procedure | How to restore state after destructive-adjacent tests | Lets the tester exercise workflows fully instead of stopping short |
The allowlist decision deserves deliberate thought. Testing through your web application firewall reflects reality but can mask vulnerable code behind a generic block. Testing with tester addresses allowlisted guarantees coverage of the application itself. The strongest pattern is to run an initial portion unfiltered, record whether the platform blocked or detected the activity, then allowlist for the remainder so the code gets properly assessed. Put both outcomes in the report.
Retesting verifies fixes to findings already reported, on the same application, within an agreed window after the report, commonly 30 to 90 days. It does not add scope and does not restart discovery. On continuous engagements, retesting happens automatically as fixes land rather than as a single event, which is the practical advantage of a subscription model over an annual test.
Telling a real engagement from a scan with a report cover. When you compare web application penetration testing services, request a redacted sample report and check seven things. Does the coverage statement list roles tested, or only URLs? Is there at least one authorization finding that required two accounts to prove? Is there a chained finding where two mediums combine into something worse? Does any finding reference your business rules rather than generic phrasing? Is evidence a captured request and response, or a plugin identifier? Are removed false positives noted? Is retesting inside the fee? A vendor who quotes from page count without asking about roles, tenancy or APIs is quoting a scan. How to evaluate a penetration test report works through the same exercise in more depth.
Stingrai has delivered offensive security engagements since 2021 from Toronto and London, is a CREST-accredited penetration testing service provider at firm level with individual testers holding CREST CRT, has published 18 CVEs, and holds 5.0 out of 5.0 across 19 Clutch reviews. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CISSP and CRTO.
Frequently Asked Questions
What is web application penetration testing?
Web application penetration testing is an authorized, time-boxed assessment in which a tester attempts to abuse an application the way a real attacker would, covering the unauthenticated surface, the authenticated surface for every user role, the APIs behind the application, and the business workflows those APIs drive. It differs from a vulnerability scan because every finding is validated with request and response evidence and chained to show real business impact. The output is a report an engineer can act on and an enterprise customer or auditor can accept.
How much does a web application penetration test cost?
Stingrai publishes web application tiers at US$3,000 one time or US$450 per month for Autonomous, and US$6,800 one time or US$1,275 per month for Hybrid, both on a twelve-month engagement covering one web application plus its APIs, with Enterprise scoped individually. Across the market, the price of a web application penetration test is driven by the number of distinct user roles, whether the application is multi-tenant, how many API endpoints exist and whether they are documented, and whether source code access is included. Ask each vendor to justify their day count against those drivers so that quotes compare on the same basis.
What is included in web application penetration testing scope?
A complete scope includes the unauthenticated surface, the authenticated surface for every supplied role including admin and support consoles, the APIs behind the application including endpoints the interface never calls, authentication and session flows, authorization at object and function level across every role pair, tenant boundaries in multi-tenant products, file handling paths, and business logic such as workflow sequencing, limits and approvals. Denial of service, destructive exploitation, social engineering, physical entry and third-party systems you do not own are normally excluded. Payment paths, production testing and source code review are typically in scope only when agreed in writing.
How long does a web application penetration test take?
Elapsed time runs longer than tester days because of account provisioning, environment access and report review. As a planning shape, a single-tenant application with two roles and fewer than thirty endpoints is a few tester days across one to two weeks, a multi-tenant product with four to six roles and a few hundred endpoints is one to two tester weeks across two to four weeks, and a platform with eight or more roles and money movement runs longer. Continuous engagements replace the single window with testing that repeats on every release.
What is the difference between black-box, grey-box and white-box web application penetration testing?
Black-box testing starts with only a URL, so a large share of the budget is spent on discovery and authorization coverage stays weak. Grey-box testing supplies credentials for every role plus API documentation, which puts the budget into permission logic and business workflows and usually returns the most coverage per dollar. White-box testing adds source code and architecture, which finds root causes and code paths the interface never exposes, and it is worth the premium for payment flows, complex permission models and regulated data.
Do vulnerability scanners find IDOR and business logic flaws?
No. Scanners reliably detect injection, transport and configuration defects because those have signatures, but broken object-level authorization, broken function-level authorization, tenant isolation failures, business logic abuse and race conditions require knowing which user should be allowed to do what, which is context a tool does not have. This is why an engagement that only produces scanner output is not a penetration test, and why authorization testing needs two accounts at the same privilege level rather than one.
How often should you run a web application penetration test?
PCI DSS v4.0.1 mandates penetration testing across a general population and CMMC requires it at Level 3 only, while ISO 27001, SOC 2, NIST SP 800-171 and NIS2 do not mandate it in that way, and ISO 27001 and SOC 2 set no frequency, so cadence there is driven by auditors, customers and insurers. Most teams settle on annually plus after any significant change, which for an application means a new authentication provider, a new role or permission model, a new payment or money-movement flow, or a major architectural change. Teams shipping weekly increasingly move to continuous testing because an annual snapshot ages out within a sprint or two.
Is retesting included after a web application penetration test?
Retesting should be inside the fee, and if a vendor charges separately you should ask why. A retest verifies fixes to previously reported findings on the same application within an agreed window, commonly 30 to 90 days after the report, and produces an updated status per finding plus a revised completion letter you can share with customers. On Stingrai's Autonomous and Hybrid tiers retests run automatically as fixes land, so verification is continuous rather than a single scheduled event.
