Most people see the report before they see the method. This is the method: seven phases, what has to be ready before the first request is sent, how long it runs, what you receive, and the things a web test deliberately leaves out.
A web application penetration test is authorised, time-boxed and mostly manual work against a running application, by people trying to use it in ways you did not design. Automated tooling appears in one phase, for coverage; it is not where the findings that change a roadmap come from.
Verizon’s 2026 Data Breach Investigations Report, built on more than 22,000 confirmed breaches across 145 countries, reports that exploitation of vulnerabilities is now the most common initial access vector for breaches, at 31%, with credential abuse down to 13%. The dominant class of web bug has not moved: in the OWASP Top 10:2025, Broken Access Control holds first place, and the project states that 100% of the applications in its contributed dataset had some form of broken access control.
Nothing is touched until the boundary is written down. Scope names the domains and hosts in play, the environment, the roles to be tested and, just as importantly, what is out: shared SaaS you do not own, payment processors, anything whose provider has not authorised testing.
That boundary lives in the rules of engagement. NIST SP 800-115 publishes a template for it in Appendix B: purpose, scope, assumptions and limitations, risks, and named contacts on each side. It also fixes the testing window, any denial-of-service exclusion, and how test traffic is marked so a real incident is never mistaken for it.
OWASP’s testing guide advises that the client should "walk the tester through the application ... before the actual test begins".
NIST SP 800-115 calls this the discovery phase and splits it in two: information gathering and scanning, then vulnerability analysis. On a web application that means inventorying what is exposed before choosing what to attack. Enumerate hosts and subdomains, fingerprint the server and framework, read the metafiles and the old files nobody removed, and map execution paths as each role in turn.
Automated scanning belongs here and nowhere else. It is good at breadth: known component versions, missing headers, default paths, public CVEs in third-party code. It is useless at everything in the next section. What comes out is an inventory of endpoints, parameters, roles and state transitions. It is not a deliverable.
This is where a web test stops looking like every other engagement. Threat modelling ranks attack scenarios by likelihood and business impact; vulnerability analysis works through them against the twelve categories of the OWASP Web Security Testing Guide, stable release 4.2.
Registration, login, password reset, lockout, multi-factor enrolment and recovery, session issue and expiry, and the channels that quietly bypass all of it. Reset flows carry more logic than login and get less scrutiny. Timing counts too: a check that holds one request at a time can fail under two, so login and single sign-on flows are exercised concurrently, not only in sequence.
Where most of the value sits. Every object identifier is manipulated from a lower-privileged session to see whether the server enforces ownership rather than the interface merely hiding the link, which is what an insecure direct object reference is. Every privileged function is called directly. In a multi-tenant application the matrix repeats across tenants.
Every parameter reaching a parser, a query, a template, a path or an outbound request: SQL injection, cross-site scripting, template injection, deserialisation, path traversal. OWASP notes that injection carries the greatest number of CVEs across the 38 weakness types under it.
Steps skipped, prices altered after the summary page, quantities set negative, workflows replayed. A business logic flaw, in OWASP’s words, "cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester".
A candidate is not a finding until it has been proved. NIST puts it plainly: "While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence."
Two things happen here that no scan can do. The first is chaining: NIST observes that most tests look for "combinations of vulnerabilities ... that can be used to gain more access than could be achieved through a single vulnerability", which is how a low-severity leak plus a forgotten endpoint becomes a compromise: a path traversal reads a configuration file, and the file holds a credential. The second is the loop back into discovery. A server-side request forgery often stops being a web finding the moment it reaches cloud metadata, and continues as a cloud engagement.
Post-exploitation measures impact instead of asserting it: what data could be read, changed or removed, and whose. Each proved finding leaves a proof of concept your engineers can replay. Restraint is part of the method: NIST notes a test "can be designed to stop when the tester reaches a point when an additional action will cause damage", so the proof stops at the last safe step.
Reporting is not the last week of the engagement. NIST describes it as running alongside the other phases, with logs kept throughout and periodic reports to management. Anything critical is reported the day it is confirmed, not saved for the document.
Once the fixes land, a retest re-runs the original tests against the original findings and records each as closed, partially fixed or still open. Partially fixed appears more often than anyone expects: the reported payload stops working and a variant of it does not. Report and attestation are reissued against the retested state.
The industry data shows what skipping this costs. The 2026 DBIR found that only 26% of critical vulnerabilities, defined there as those in the CISA Known Exploited Vulnerabilities catalogue, were fully remediated by organisations during 2025, down from 38% the year before, while the median time to full resolution rose to 43 days from 32.
For a single web application, plan on one to two weeks of active testing, preceded by roughly a week for scope, paperwork and access, and followed by reporting. The retest is shorter and comes weeks later. Those are planning ranges: the introductory meeting turns them into dates.
What moves the number is not the page count. It is:
If an auditor asks which methodology your test followed, the answer should be a document they can open. The web application pentesting service page lists what we test and what we need from you.
The real sequence of an external network penetration test: scope and rules of engagement, reconnaissance, perimeter analysis, exploitation, reporting and retest, plus what the test will not cover.
The sequence of a real internal network penetration test: the starting point we agree, what a domain account becomes, what you get at the end, how long it takes and what the exercise deliberately does not cover.
A plain account of an API penetration test from the rules of engagement to the retest: what happens in each phase, what you get at the end, and the limits of what the test can tell you.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
