Overview
A web application penetration test is a manual, time-boxed attempt to compromise your application the way a motivated attacker would: with real accounts, against real business logic, chaining small weaknesses into one that matters.
Every engagement starts by mapping the feature set before the vulnerability set. Roles, plans, tenancies, invitation flows, billing states, admin surfaces, feature flags, once the state machine is understood, testing targets the transitions between states rather than isolated endpoints. That is where the expensive bugs live.
Engagement at a glance
- Typical duration
- 5 to 15 working days, depending on authenticated surface
- Accounts needed
- At least two per role, cross-account testing is where IDOR and tenancy bugs surface
- Testing style
- Manual exploitation, source-aware; tooling used for coverage, never for findings
- Standards
- OWASP Web Security Testing Guide, OWASP ASVS, PTES
- Deliverable
- Engineer-grade report with reproducible PoCs plus an auditor-facing summary
- Retest
- Included, findings close only when re-exploitation fails
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Authentication and session management
- Authorisation, IDOR and multi-tenant isolation
- Business logic and workflow abuse
- Injection (SQL, NoSQL, command, template)
- Cross-site scripting: stored, reflected, DOM and mutation
- CSRF, CORS and cross-origin messaging
- Server-side request forgery and internal pivoting
- File upload and deserialisation
- JavaScript bundle analysis and client-side control bypass
- Rate limiting, race conditions and state transitions
- Password reset, MFA and account lifecycle
- Known CVEs on the deployed stack
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Broken access control | Every object reference replayed across two accounts and every role, including delete and export paths | Cross-tenant data read, silent record deletion, full account takeover |
| Business logic | Pricing, quotas, refunds, trial limits, workflow-step skipping, negative and decimal values | Paid features obtained free, balance manipulation, approval bypass |
| Authentication | Reset-token lifecycle across email and password changes, MFA enrolment races, session fixation and invalidation | Account takeover without user interaction |
| Injection | Parameterised and second-order SQL, NoSQL operators, template engines, OS command paths | Database read/write, remote code execution |
| Server-side request forgery | URL parameters, webhooks, PDF and image processors, redirect chains, cloud metadata | Internal service access, credential theft from instance metadata |
| Client-side | Stored and DOM XSS, prototype pollution, postMessage listeners, service worker scope | Session theft, persistent compromise of other users |
| Race conditions | Single-packet attacks against limits, invites, coupons, withdrawals and state transitions | Limit bypass, duplicate spend, privilege escalation |
| Exposure | Source maps, .git and .env paths, backups, debug endpoints, secrets in JavaScript bundles | Credential disclosure leading to direct compromise |
What we commonly find
Tenancy boundaries that hold on read but not on write
Applications frequently scope GET requests correctly and forget PUT, PATCH and DELETE, or the CSV export that runs on a different code path.
Password reset tokens that survive a state change
A token issued before an email change still works after it. Issue, transition, consume, tested as a matrix, not as three isolated checks.
Roles enforced only in the front end
Admin routes hidden in the UI but reachable by calling the API directly, usually discovered by reading the JavaScript bundle rather than the documentation.
Chains, not singles
A self-XSS plus a CSRF plus a permissive CORS policy is three low findings on a scanner report and one account takeover in practice.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Before an enterprise security review or a customer security questionnaire.
- Ahead of a SOC 2 Type II or ISO 27001 audit that expects annual testing evidence.
- After a significant release: new authentication, new roles, a new tenancy model or a payments integration.
- On a recurring annual or semi-annual cadence once the application is in production.
Questions
How is this different from a vulnerability scan?
A scan sends known payloads at known patterns and reports what echoes back. It cannot log in as two different users and compare what each can reach, and it has no concept of what your application is for. Every finding in this engagement is manually reproduced and rated on real business impact, scanner output is used only to widen coverage, never as a finding.
Do you need production access?
A staging environment that mirrors production is preferred, with production-equivalent data volumes and the same authentication stack. Testing against production is possible with agreed rate limits, a maintenance window for any intrusive test, and a documented rollback path.
How many accounts should we provision?
Two accounts per role, minimum, plus two separate tenants or organisations if the product is multi-tenant. Without a second account, IDOR, cross-tenant access and privilege escalation cannot be demonstrated, and roughly 40% of the meaningful attack surface goes untested.
What happens after the report?
A remediation walkthrough with your engineers, then a retest of every finding in a clean session. A finding closes only when re-exploitation fails. The retest is included in the engagement, not billed separately.
Will testing break our application?
Destructive techniques (denial of service, mass data deletion, resource exhaustion) are out of scope by default and only performed on written request against a non-production target. Every request sent is logged, so any anomaly can be traced to the exact payload that caused it.
How much does a web application penetration test cost?
Cost follows scope rather than a price list. The inputs are the number of applications, how many distinct user roles and tenancies exist, whether an API is in scope, and whether source code is available. A fixed quote is issued after a short scoping call, with no hourly billing and no change orders unless you change the scope. Our published minimum engagement is $10,000.
How long does a web application penetration test take?
Most single-application engagements run five to ten working days of testing, plus two to three days for reporting. Multi-tenant platforms with several roles take longer because every role pair has to be tested against every other. You get the schedule in writing at scoping, and critical findings are escalated the same day rather than held for the report.
What standard do you test against?
OWASP Top 10 and OWASP ASVS for coverage, with the testing itself driven by the application's own logic rather than by a checklist. A checklist finds what everyone else finds. Broken access control and business logic flaws, which cause most real breaches, only appear when a tester understands what the application is for.
Do you test single-page applications and frameworks like React or Angular?
Yes, and the client framework changes what matters rather than how much. JavaScript bundles are pulled and read for endpoints, keys and role strings that the interface never exposes, and every control enforced only in the browser is tested against the API directly. A rule the front end applies is not a rule until the server applies it too.
Can you test a staging environment instead of production?
Yes, and it is often preferable. The requirement is that staging matches production in code, configuration and roles; a staging environment with debug endpoints open or authentication relaxed produces findings you cannot act on and hides the ones you need. Where the two differ, the report says which findings were confirmed against which environment.
Is retesting included?
Yes. Every finding is retested in a clean session after you remediate, and closed only when re-exploitation fails. You receive a signed attestation letter recording what was raised, what was fixed and what was verified. A test without retesting is incomplete by design, so it is included rather than sold separately.