OWASP Web Security Testing Guide: latest methodology
The OWASP Web Security Testing Guide (WSTG) is the official OWASP methodology for testing web applications, and its latest stable version is 4.2, while version 5.0 is in development. It organises testing into twelve categories, from information gathering to API testing, and places them inside a five-phase framework that runs through the whole development lifecycle. It is free to read, and it is most useful as a way to define what an audit must actually cover.
I am a freelance web developer in France and I sell application development and maintenance, so I have an interest in this topic. This article is written for the person commissioning a review, not only for the tester.
What is the latest version of the OWASP Web Security Testing Guide?
The official project page lists 4.2 as the latest version, available as a web release and a PDF, and states that release 5.0 is being developed. The page does not give a release date for 5.0, so be wary of anyone quoting one. When you read a proposal, check which version it cites: it should be easy for the provider to tell you. If they follow the development branch instead, that can be fine, but it should be stated openly.
The v4.2 table of contents is short at the top level: introduction, the testing framework, web application security testing, and reporting, plus appendices on tools, reading, fuzz vectors, encoded injection, history and browser developer tools.
The official methodology: twelve testing categories
Section 4 is the part most people mean when they mention the WSTG. Here is how I would explain each category to a non-specialist. The names are OWASP's own, the plain-language column is mine.
| WSTG section | Category | The question in plain language |
|---|---|---|
| 4.1 | Information Gathering | What can an outsider learn about the application? |
| 4.2 | Configuration and Deployment Management | Is the server set up safely? |
| 4.3 | Identity Management | How are accounts and roles created? |
| 4.4 | Authentication | Can someone get in without the right credentials? |
| 4.5 | Authorization | Can a user reach another user's data? |
| 4.6 | Session Management | Can a logged-in session be stolen or reused? |
| 4.7 | Input Validation | Can crafted input trigger injection flaws? |
| 4.8 | Error Handling | Do error messages leak details? |
| 4.9 | Weak Cryptography | Is data protected with sound methods? |
| 4.10 | Business Logic | Can the rules of the service be abused? |
| 4.11 | Client-side | Can the browser side be manipulated? |
| 4.12 | API | Are the APIs behind the app exposed? |
Authorization and business logic deserve your attention. They depend on what your application is meant to do, so a tool cannot judge them on its own. Broken access control also sits first in the OWASP Top 10:2025, which is a list of risks and not a test plan.
A testing framework, not only a penetration test
What surprises many buyers is how modestly the guide treats penetration testing (a simulated attack from outside). The framework has five phases: before development begins, definition and design, development, deployment, and maintenance and operations. Penetration testing appears at deployment, as an additional check after requirements, design and code review. The guide says it "has a role to play" but is "generally inefficient at finding bugs and relies excessively on the skill of the tester."
The introduction sets out four techniques: manual inspections and reviews, threat modeling, source code review, and penetration testing. It stresses that no single technique is enough and warns that a superficial review can create false confidence. It also explains why automated scanners struggle with custom applications: its example is a hidden parameter that a code review would reveal at once and a scanner would have to brute-force.
The practical consequence is this: a one-week external test of an application you built years ago gives you a useful snapshot of the exposed surface, not proof that the application is safe. Ask what the test did not look at.
How to use the WSTG to commission an audit
You do not need to read the whole guide to benefit from it. First, ask the provider to map their scope against the twelve categories and say plainly which ones are excluded and why. Second, ask whether they will have test accounts for each role, since authorization testing is hard without them. Third, ask whether source code review is included. Fourth, ask for a sample of the report: section 5 of the guide is devoted to reporting, and a report you cannot act on has little value. Finally, get written permission before any test, from your own company and from your hosting provider where needed. Testing systems you do not control is not a formality to skip.
OWASP also lists other methodologies, including PTES, NIST 800-115 and OSSTMM, with the last being broader than web application testing. If your contract or sector names one of them, follow that requirement rather than the WSTG alone.
When this is the wrong tool, and when I am the wrong person
If you run a small brochure site with no accounts or personal data, a full WSTG review is out of proportion. Keeping software updated, restricting admin access and testing backups will do more. If you are in France, the CNIL's guidance on securing websites is a sensible starting point, and it suggests regular vulnerability tests with tools such as OWASP ZAP.
If a client, insurer or regulator expects an independent attestation, hire a specialist security auditor. Whoever builds or maintains your application, me included, should not be the only one marking their own work. Ask any provider for proof that matches your case.
Where I can help is on the developer side: reviewing an existing PHP, Symfony or React application against these categories, then fixing what is found. You can see what I do on the web application page, or describe your application and you will speak directly with the person who reads and writes the code.