The OWASP Testing Guide, and how to tell a real penetration test from a scan

The Web Security Testing Guide is a public, community-maintained methodology for testing web applications. It sets out categories — information gathering, configuration, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic, client-side — and within each, specific test cases with the reasoning behind them. There are several hundred.

It is not a tool, not a certification, and not something a firm can be "accredited" in. What it is, is a shared account of what a thorough test covers — which is precisely what makes a report citing it checkable by somebody who was not in the room.

The stable release is version 4.2, published in 2020, with version 5.0 in development to cover newer ground including modern authentication flows. That age is worth knowing rather than hiding: a good tester works to the published methodology and supplements it, and a good report says which version it followed.

This is the single most useful thing to understand before buying a test, because the phrase appears in a great many proposals and it does not mean what a buyer assumes.

The Top 10 is an awareness document. It names the ten most significant categories of web application risk, it is revised every few years — the 2025 edition is current, and it introduced Software Supply Chain Failures and Mishandling of Exceptional Conditions as categories while folding Server-Side Request Forgery into Broken Access Control — and it is genuinely useful for prioritisation and for explaining risk to a board.

It is not a test plan. Ten categories cannot tell you what was executed. A proposal promising to test "against the OWASP Top 10" has described its priorities; a proposal working to the Testing Guide can tell you which test cases were run, which were not applicable and why. Those are different products, and they are frequently the same price.

Which methodology, and which version. "OWASP" is an organisation, not an answer. A tester who cannot name the document and its edition has told you something.

What is in scope and what is not — hosts, applications, environments, the roles and credentials the tester will hold. Grey box, where the tester gets credentials for each role, returns more findings per rupee than black box, because the budget goes on authorisation boundaries and business logic rather than on rediscovering an architecture you could have handed over in an hour.

Who performs it, and what they have done before. And whether a retest is included: the retest letter, not the original report, is what demonstrates to a customer or an auditor that findings were closed. Buying the test without the retest is buying half the evidence.

The methodology named with its version. Scope, stated precisely. The dates testing ran. Who performed it.

For each finding: steps somebody else can follow to reproduce it, the evidence, a severity on a named scale — CVSS, usually — and remediation guidance specific to your stack rather than a paragraph lifted from a vulnerability database. A finding you cannot reproduce is a finding your engineers will quietly deprioritise.

An executive summary that a non-technical reader can act on, and a findings section an engineer can pick up without translation. These are two audiences and a report that serves only one of them will be read by only one of them.

The section that separates a professional report from a generated one is the part describing what was NOT tested: the module out of scope, the environment that was unavailable, the test class excluded by the rules of engagement, the area where time ran out.

That is not a weakness in the report. It is the thing that makes the rest of it trustworthy — and it is what an auditor reading the report a year later most wants to see, because it tells them what the test does and does not evidence.

A report with no limitations section is claiming complete coverage of an application, which no test of finite length achieves. Treat its absence as a finding of its own.