Web Application Pentest Methodology: What Testers Find

The 2026 Verizon Data Breach Investigations Report confirmed a shift the report itself calls a first in its 19-year history: “Using software flaws (31%) has surpassed stolen credentials for the first time” as the leading way attackers get in. That single finding has moved the web application penetration testing methodology conversation out of the compliance folder and onto the Q3 board agenda for finance, healthcare, and technology firms alike.

CTDefense runs manual web app engagements the way a determined attacker would. The team maps how access controls are supposed to work, tests what the application expects against what it actually accepts, and chains small logic gaps into demonstrable impact. This piece walks through what a senior tester does across four vulnerability classes, and what the resulting report looks like when it lands on a CISO’s desk.

Why 2026 Changed the Business Case for Web App Testing

Software exploitation overtaking stolen credentials matters because credential hygiene is a program most large organisations already run. Application-layer risk is not. When 31% of breaches start in the code you ship rather than the passwords your staff type, the cost-benefit of a proper web application security assessment changes.

Two other signals reinforce the shift. OWASP still places Broken Access Control at position A01 in the 2025 Top 10 revision, holding the top slot from the previous edition. And PortSwigger’s Top 10 Web Hacking Techniques of 2025 awarded first place to “Successful Errors: New Code Injection and SSTI Techniques,” which “introduces new error-based techniques for exploiting blind server-side template injection.” Both point to the same buyer question: what actually happens during a manual engagement, and how is that different from a scanner run?

Broken Access Control and BOLA: The Access Matrix Approach

The OWASP A01:2025 Broken Access Control entry reports that “100% of the applications tested were found to have some form of broken access control.” Every single one. That number is the strongest argument for broken access control testing performed by a human who understands what “supposed to” means in the target application, because no scanner models the intended permission boundaries of an app it has never seen before.

The CTDefense team begins by building an access control matrix. Every role the application exposes (guest, standard user, tenant admin, platform admin, support agent) is mapped to every resource endpoint the application serves. The tester then authenticates as each role in turn and walks the matrix cell by cell, checking whether the application enforces the intended boundary or leaks around it.

This is where BOLA (Broken Object Level Authorization) findings surface. The tester takes an authenticated request that legitimately returns object 1000 and rewrites it to request object 1001. If the response returns object 1001 with no ownership check, the team has proven horizontal privilege escalation. The same technique, applied vertically, catches endpoints that trust a client-side role flag or a JWT claim without server-side verification.

For teams that want to see how OWASP A01:2025 maps to real pentest findings, the pattern is consistent: broken access control is not a single bug class, it is a category of gaps between what the developer assumed and what the deployed code accepts.

Blind SSTI and ORM Leaks: Server-Side Injection Paths

Server-side template injection is the case where user-controlled data reaches a template renderer and gets evaluated as template syntax rather than displayed as text. Classic SSTI produces a visible error containing a rendered payload. Blind SSTI produces no such error, and this is exactly the reason the PortSwigger community ranked the 2025 research at position one: the new techniques recover template context from side-channel signals (timing, response length, error-page differentials) rather than from a rendered response body.

CTDefense testers probe blind SSTI by injecting engine-specific expressions into every user-controlled input that touches HTML output, email templates, or PDF generation flows. Payloads for Jinja2, Twig, Freemarker, ERB, and Handlebars each produce distinct measurable behaviour on the server, even when nothing renders back to the tester. Automated tools rarely chain these signals because they parse HTTP responses without rendering template context; that is a direct answer to how a web app pentest differs from a vulnerability scan. A scan matches known signatures against a database. A pentest proves exploitability by chaining behaviour the scanner never had a rule for, maps intended authorization flows, and finds logic errors no signature file can model.

ORM leaks are the same pattern in a different layer. Search endpoints, filter parameters, and sort fields often accept structured query fragments that map directly into the underlying ORM. The tester supplies operator-shaped input (a nested filter, a relation traversal, a negation clause) and observes whether the query returns rows the current user should not see. This class overlaps closely with the class of web vulnerabilities DAST tools skip, because the input looks syntactically valid and the response looks syntactically clean; only the row count and the row identities reveal the leak.

Business Logic Flaws: Testing the Application’s Intended Rules

Business logic vulnerability testing is the part of the engagement that no scanner can generalise, because the rules being tested are unique to the specific application. A pentester needs to understand what the application is trying to do before they can find the ways it can be tricked into doing something else.

A CTDefense engagement typically covers four business logic patterns per application:

• State-machine bypass. The application expects a checkout to move from cart to payment to fulfilment; the tester posts fulfilment first, or posts payment twice, or posts a refund against an order that was never charged.
• Rate and quantity abuse. Coupon codes, referral rewards, trial extensions, and free-tier quotas frequently rely on a client-side counter or a single database write. The tester issues concurrent requests, negative quantities, and integer overflow inputs to see which controls hold.
• Cross-tenant contamination in SaaS. In multi-tenant platforms, the tester creates two accounts in different tenants and looks for identifiers (report IDs, upload URLs, notification tokens) that cross the boundary.
• Workflow race conditions. Two-step operations that check an eligibility rule at step one and act on it at step two are tested with a race between the two calls, which sometimes bypasses the check entirely.

Together, a human-led engagement covers access control matrix mapping, template and injection probing, ORM enumeration, and business logic walkthrough, each delivered with proof-of-concept steps and CVSS-rated findings. That is what a web app pentest actually includes when a senior tester runs it.

What the Engagement Report Delivers

The report is the artefact the CISO reads and the auditor keeps on file. A CTDefense web application pentest report contains, for each finding: a plain-language description of the vulnerability, the CVSS 3.1 vector and score, the reproduction steps a developer can follow, the affected endpoints and parameters, the observed impact demonstrated during the engagement, and prioritised remediation guidance mapped to the OWASP Top 10 category.

The same document supports ISO 27001 penetration testing evidence requirements under control A.8.29 and the equivalent NIS2 technical measures, so the developers get a fix list and compliance gets an audit-ready record from a single deliverable. On cadence, most regulators expect testing at least annually and after any significant architecture or release change; regulated buyers in the most exposed sectors often step to a quarterly rhythm on the most exposed applications.

CTDefense delivers this engagement as Web Application Penetration Testing, a manual assessment led by a senior tester against a scoped application, on a black-box or authenticated grey-box basis depending on the buyer’s goals.

Finance, healthcare, and technology firms sitting on a Q3 board review that references the DBIR 2026 milestone have a straightforward next step: commission a manual engagement that exercises access control, injection, and business logic rather than accept a scanner export as evidence. Similar organisations preparing for an ISO 27001 or NIS2 audit in the next two quarters can use the same engagement to satisfy the testing-evidence requirement without adding a second workstream.