Ninety percent of the “penetration test reports” we’ve reviewed from other vendors are a vulnerability scanner’s PDF export with a logo on it. Missing security headers, an outdated library version, a couple of low-severity findings, and a bill. No authentication flows tested. No business logic touched. No proof that a human ever looked at the application.
That gap is the entire reason web application penetration testing exists as a discipline separate from vulnerability scanning. This guide covers what a real web app pentest actually involves, how manual testing differs from automated scanning, what OWASP’s current risk list covers, and what a report worth paying for should contain.
In this guide:
- What web application penetration testing is
- Manual testing vs automated scanning
- What OWASP Top 10 (2025) covers
- Business logic flaws scanners can’t find
- What to expect: process and timeline
- What a real report contains
- FAQ
What Is Web Application Penetration Testing?
Web application penetration testing is a manual, authorized simulation of a real attack against your application, carried out by a person who understands how attackers actually think, not just what a scanner’s signature database recognizes. The tester examines authentication, session management, access control, input handling, and the specific business logic of your application, then attempts to exploit what they find to confirm it’s a real, working vulnerability rather than a theoretical one.
This is different from a vulnerability scan, which is automated, fast, and limited to patterns the tool already knows how to recognize.
Manual Testing vs Automated Scanning
Both have a place. The mistake is treating one as a substitute for the other.
| Automated Scanning | Manual Penetration Testing | |
|---|---|---|
| Speed | Minutes to hours | Days to weeks |
| Finds known vulnerability patterns | Yes | Yes |
| Finds business logic flaws | No | Yes |
| Finds broken access control across user roles | Rarely | Yes |
| Chains multiple low-severity issues into a real attack path | No | Yes |
| False positive rate | Higher | Lower — findings are manually verified |
| Proof of exploitability | No | Yes, with PoC |
Table: What each approach actually catches.
A scanner is good at finding a missing security header or an outdated JavaScript library in seconds across thousands of pages. It cannot tell you that a logged-in user can change a URL parameter and view another customer’s invoice, because that’s not a signature-matchable pattern — it’s a contextual understanding of what the application is supposed to do versus what it actually lets you do.
What OWASP Top 10 (2025) Covers
OWASP’s current edition — the 2025 release, which replaced the long-standing 2021 list — still ranks Broken Access Control as the #1 web application risk, alongside Security Misconfiguration and a growing emphasis on supply chain risk in modern dependency-heavy applications.
A pentest that claims to be “OWASP-aligned” should be systematically testing against each of these categories, not cherry-picking the easy ones. In practice, three categories account for most of what we find in real engagements:
- Broken Access Control — a user accessing data or functions outside their intended permissions, most commonly through predictable object IDs or missing server-side authorization checks
- Security Misconfiguration — exposed debug endpoints, default credentials left in place, verbose error messages leaking stack traces or internal paths
- Injection — SQL injection is less common in modern frameworks with parameterized queries by default, but shows up reliably in legacy code paths, admin panels, and hand-rolled search features
The OWASP Top 10 is not a compliance checklist and OWASP itself doesn’t present it that way — it’s a consensus view of where the damage concentrates. Treat it as a floor for scope, not the entire scope.
Business Logic Flaws: What Scanners Can’t Find
This is where manual testing earns its cost. Business logic flaws aren’t bugs in the traditional sense — the code runs exactly as written. The problem is that what it was written to do creates an exploitable gap.
A common pattern: an e-commerce checkout flow that calculates the final price client-side and trusts what the browser sends back. A scanner sees a normal-looking checkout request and moves on. A manual tester intercepts the request, changes the price field, and completes a real purchase for a fraction of the cost — because nothing on the server ever re-validated the number.
Another recurring one in SaaS products: a “downgrade” API endpoint that removes a paid feature from a user’s account correctly, but a parallel “upgrade” endpoint that doesn’t check whether the account is actually authorized to have that feature enabled, letting any authenticated user grant themselves premium access directly.
Neither of these trips a scanner. Both are a straightforward find for a tester who spends time actually using the application the way an attacker would.
What to Expect: Process and Timeline
A properly scoped web application pentest generally follows five phases:
- Scoping — defining which applications, user roles, and environments are in scope, along with any compliance requirements (PCI DSS, SOC 2, ISO 27001) driving the engagement
- Reconnaissance and mapping — understanding the application’s architecture, authentication flows, and attack surface before touching anything
- Automated scanning — a first pass to clear the obvious, known-pattern issues quickly
- Manual testing — the core of the engagement: business logic, access control across every user role, authentication and session handling, and chaining findings into real attack paths
- Reporting and retest — a written report with evidence and remediation guidance, followed by verification once fixes are in place
For a mid-sized web application, this typically runs one to two weeks. Larger, multi-role SaaS platforms with complex authorization models take longer — rushing this phase is usually where “cheap” pentests cut corners.
What a Real Report Should Contain
If a report doesn’t make your next steps obvious, it hasn’t done its job. At minimum, expect:
- An executive summary a non-technical stakeholder can actually use
- Every finding with a CVSS score, clear reproduction steps, and evidence (screenshots or request/response pairs)
- Proof of concept for anything exploitable, not just a description
- Business impact stated in plain terms, not just a severity label
- A prioritized remediation roadmap, not just a list of problems
- A free retest once fixes are applied, to confirm they actually worked
If a vendor can’t show you a sample report before you sign, that’s worth asking about directly.
FAQ
How long does a web app pentest take?
Most mid-sized applications take one to two weeks from kickoff to draft report. Complex, multi-role SaaS platforms or applications with a large number of integrations can take three to four weeks.
What does a web app pentest report include?
An executive summary, detailed findings with CVSS scores and evidence, proof of concept for exploitable issues, business impact, and a prioritized remediation roadmap — plus a free retest after fixes.
Is a vulnerability scan the same as a penetration test?
No. A vulnerability scan is automated and pattern-based. A penetration test includes manual testing by a human who verifies findings, tests business logic, and confirms real exploitability — something a scan alone cannot do.
How often should I pentest my web application?
At minimum annually, and after any major code or infrastructure change. Many compliance frameworks (SOC 2, PCI DSS) require this cadence explicitly.
Can automated tools replace manual penetration testing?
No. Automated tools are a useful first pass for known-pattern issues, but they consistently miss business logic flaws and access control failures across user roles, which is where the most damaging real-world vulnerabilities tend to live.
Get a Web Application Pentest That Actually Finds What Matters
A scanner report with your logo on it won’t hold up in an investor’s due diligence review or a serious security audit. Book a free 30-minute consultation and we’ll scope a manual web application and API penetration test built around how your application actually works, not a generic checklist.