Web App Vulnerabilities Your Scanner and WAF Miss
The web application vulnerabilities scanners miss are rarely the ones a CVE feed will tell you about. They sit one layer above signatures, in the logic of how an application decides who is allowed to do what, and they are the techniques that won the practitioner vote in PortSwigger’s Top 10 Web Hacking Techniques of 2025. The community nominated 63 pieces of original research this year, and the winners share a pattern: error-based blind server-side template injection, ORM leakage chains, HTTP-redirect-loop SSRF. None of them look like a payload a WAF rule was written to block.
This matters more this year than last. The Verizon 2026 DBIR confirms that software vulnerability exploitation is now the #1 initial access vector at 31% of breaches, beating stolen credentials for the first time in the report’s 19-year history. The pressure is no longer about stopping phishing; it is finding the exploitable flaw before someone else does.
CTDefense sees the same gap from the engagement side. A scanner finishes its run and reports 200 medium-severity hits, all CVE-tagged. A WAF dashboard shows 14,000 blocked requests, all signature matches. The CISO looks at both and asks the question every CISO eventually asks: what is the application doing that neither of these tools can see?
Why Scanners and WAFs Have the Same Blind Spot
A scanner and a WAF are doing the same job at different points in the request lifecycle. The scanner fires known payloads at known parameters and pattern-matches the responses. The WAF inspects the same request shape inline and blocks anything that looks like a known payload. Both are signature engines. Both are excellent at the work they do.
The work they do does not include business logic flaws web pentest engagements are built to find. A business logic flaw is not a payload, so there is no signature. The request looks legitimate. It often is legitimate, syntactically; what is wrong is that the application accepted it from a user who should not have been allowed to send it, against a resource that should have been out of scope, in a state the workflow should not permit. Examples from real engagements: a checkout endpoint that lets a user set the price of an item to a negative number, a password-reset flow that does not invalidate the previous token, an admin export endpoint that responds to any authenticated session because the role check lives in the frontend.
The same blind spot covers chains of low-severity issues. A scanner reports two findings: an HTTP redirect with an open next= parameter (low severity) and a webhook receiver that follows redirects internally (low severity). Neither is interesting alone. Chained, they are the SSRF that reaches the cloud metadata service.
Three of the 2025 PortSwigger winners illustrate the gap plainly. The next three sections walk through each one.
Error-Based SSTI: Remote Code Execution Without a Payload
Server-side template injection has been on offensive-research radars for years. The 2025 entry that won the vote raised the bar on blind variants. The technique exploits applications that pass user-controlled input into a template engine without rendering its output to the user, then leaks the result through error messages or timing.
A scanner cannot detect this directly. The standard SSTI payloads expect a visible reflection of the template output. When that reflection is absent, signature checks return no finding. A WAF cannot detect it either, because the input that triggers the bug often looks like a perfectly normal product name, search term, or comment body. The exploit only becomes obvious when the template engine throws a specific error class, or when the response time changes by a measurable amount depending on what the template was asked to compute.
A pentester finds this the way a human always has: by reading the application’s behavior on edge cases the scanner does not know to send. Proof-of-exploit usually involves chaining the error-leak primitive into command execution in the template engine’s underlying runtime, which is the part the buyer cares about. A scanner that reports “input may reflect in template context” is not the same artifact as a pentest report that says “the team achieved remote code execution as the application user, evidence attached”.
ORM Leakage Chains: When Your Search Field Becomes a Data Leak
The second class is quieter. Modern web applications lean heavily on ORMs (Active Record, Sequelize, Prisma, SQLAlchemy, Entity Framework). The ORM is supposed to keep the developer out of SQL-injection trouble, and for the most part it does. The 2025 research showed that the ORM’s own query-construction surface can become a leakage primitive when user input is allowed to influence which fields are loaded, which relations are eagerly fetched, or how a filter is composed.
The pattern looks like this: a search endpoint accepts a JSON body that maps cleanly to ORM filter syntax. The developer assumed the user could only filter on fields they could already see. The ORM did not enforce that assumption, and the attacker uses the filter language to compare against fields they cannot see (password hashes, reset tokens, internal flags) one bit at a time. The endpoint never returns those fields directly. It returns the count of matching records, and the count is enough.
The OWASP Foundation classifies this kind of issue under Broken Access Control in the OWASP Top 10:2025, where the 2025 update folds object-level and function-level API authorization gaps (BOLA and BFLA) into the same category. The dataset behind the list shows 3.73% of applications tested had one or more of the 40 CWEs covered by Broken Access Control, keeping it at #1 across 2.8 million applications. The bridge from OWASP Top 10 2025 web testing into a real engagement is exactly this: the list tells you the category, the engagement tells you whether your application has the specific instance.
HTTP-Redirect SSRF: How Internal Services Get Exposed
The third winner is HTTP-redirect-loop SSRF. The setup: an application accepts a user-supplied URL (a webhook target, an image URL, an OAuth callback), validates it once against an allowlist, then makes the request. The validation passes because the URL points to a host the application is willing to talk to. The host returns an HTTP redirect to an internal address. The application follows it.
The reason the WAF does not catch this is that the malicious request never leaves the user-controlled side. Everything visible to the WAF is a request to a legitimate external URL. The exploit happens on the server’s outbound side, against the cloud metadata service or an internal admin panel, after a redirect the WAF cannot inspect. The reason the scanner does not catch this is similar: scanners check whether the input URL field accepts internal addresses directly, find that it does not, and move on. They do not test the redirect chain.
Proof-of-exploit looks like a fetched IAM credential or an internal endpoint screenshot, attached to the report alongside the request sequence that produced it. That is the artifact that gets remediation prioritized in the next sprint. “Possible SSRF, severity medium” sits in a backlog.
What Proof-of-Exploit Testing Actually Closes
The three classes above answer the most common question from buyers evaluating their stack: what does a WAF not protect against. The short answer is anything that depends on the application’s intent rather than the request’s payload, and anything that requires chaining two low-severity findings into a critical path. A WAF blocks payload signatures. It cannot evaluate whether a request violates business logic or accesses data it should not.
The companion question is how often should web applications be penetration tested. Most compliance frameworks (PCI DSS, ISO 27001, NIS2, DORA) require at least annually, and that is the floor, not the ceiling. Every significant release or infrastructure change introduces new attack surface. The PortSwigger list is itself an annual snapshot of techniques the community discovered during the previous year; the techniques in next year’s list are already being exploited somewhere.
The related question is what is the difference between a vulnerability scan and a web pentest. A scanner flags known CVEs and misconfigurations against a signature database. A web pentest proves exploitability by chaining findings, by testing logic the scanner has no rule for, and by producing the artifact (a screenshot, a credential, a session token) that ends the debate about whether the issue is real.
For organizations already running annual engagements, the harder question is the gap between them. A 12-month cadence leaves 11 months of code changes, infrastructure changes, and new feature surface untested at the depth of a real engagement. CTDefense closes that gap in two ways: a senior-led web application penetration testing engagement once or twice a year for the deep work, and continuous web application testing between engagements using an autonomous AI pentest platform like PentX for the regression-level checks that should not wait for the next annual cycle. The split is honest about what each layer does: the platform reproves exploitability on the 12 to 15 most common authn, authz, and logic-regression patterns after every meaningful release; the human engagement covers novel architecture and the chained exploitation that needs a senior brain on the keyboard.
That split also addresses how AI-assisted pentests work in practice, which is the part most buyers want to understand before they sign for continuous testing: what the platform reliably catches, where it defers to human review, and how the findings land in the same report format the compliance auditor already accepts. For a longer view of how this maps to the framework most security teams already track, how real pentest findings compare to the OWASP list walks through the categories where the gap between published list and engagement reality is widest.
CTDefense continues to support finance, SaaS, and technology companies running a recognizable stack of scanners, WAFs, and annual third-party pentests. Similar organizations are encouraged to look at the gap between those layers rather than at the layers themselves; the techniques that win community votes year after year sit in that gap by design. A web application security assessment that proves exploitability, repeated at a cadence that matches the release schedule, is what closes it.