The OWASP Web Security Testing Guide (WSTG) is the most widely used open methodology for testing the security of web applications, and it is the reference most professional testers structure their work around. Version 4.2 catalogs hundreds of discrete tests across 12 categories, each tagged with a stable identifier such as WSTG-INPV-01, so two testers on two continents can run the same check and mean the same thing.
This guide explains what the WSTG actually contains, how its categories and test IDs work, how it differs from the OWASP Top 10, and how you put it to work in a real engagement with tools like Burp Suite and sqlmap. By the end you should be able to read a finding labeled WSTG-ATHN-03 and know exactly what was tested.
The OWASP Web Security Testing Guide is a free, community-maintained framework that defines how to test a web application for security flaws, end to end. It is published by the Open Worldwide Application Security Project and is currently at stable version 4.2, with a 5.0 rewrite underway.
WSTG is descriptive and procedural. For each test it gives you a summary of the issue, a set of black-box and gray-box test steps, example payloads, and remediation guidance. It assumes you are working through an application methodically rather than firing a scanner and reading the output. That structure is exactly why it pairs well with a hands-on web application pentesting checklist and a defined set of penetration testing steps and test cases.
WSTG groups its tests into 12 categories, each with a short code used in the test IDs. They run roughly in the order you would test an application, from passive recon through to client-side issues. The categories are Information Gathering (INFO), Configuration and Deployment Management (CONF), Identity Management (IDNT), Authentication (ATHN), Authorization (ATHZ), Session Management (SESS), Input Validation (INPV), Error Handling (ERRH), Cryptography (CRYP), Business Logic (BUSL), Client-side Testing (CLNT), and API Testing (APIT).
The first eleven have existed since 4.x; API Testing was formalized as the application surface shifted toward services. If you test APIs heavily, treat APIT as a jumping-off point and pair it with dedicated API penetration testing methodology.
Every individual test has a stable ID of the form WSTG-<CATEGORY>-<NUMBER>, and that ID never changes between minor revisions, which is what makes coverage auditable. For example, WSTG-INPV-01 is Testing for Reflected Cross Site Scripting, WSTG-INPV-05 is Testing for SQL Injection, WSTG-ATHN-03 is Testing for Weak Lockout Mechanism, and WSTG-SESS-02 is Testing for Cookies Attributes.
In a report, citing the ID does two things. It proves you tested a specific control, and it lets a reviewer pull the official OWASP page to see the exact procedure you followed. A finding that just says "XSS" is weaker than one that says "Stored XSS, WSTG-INPV-02, on the profile bio field."
WSTG-INFO-* Information Gathering
WSTG-CONF-* Configuration & Deployment
WSTG-IDNT-* Identity Management
WSTG-ATHN-* Authentication
WSTG-ATHZ-* Authorization
WSTG-SESS-* Session Management
WSTG-INPV-* Input Validation
WSTG-ERRH-* Error Handling
WSTG-CRYP-* Cryptography
WSTG-BUSL-* Business Logic
WSTG-CLNT-* Client-side
WSTG-APIT-* API TestingThe OWASP Top 10 is an awareness document that ranks the ten most critical web risk categories; WSTG is the methodology you use to actually find instances of those risks. They are complementary, not competing. The Top 10 answers "what should I worry about," WSTG answers "how do I test for it."
In practice you test with WSTG and report against both. A SQL injection you find via WSTG-INPV-05 maps to A03:2021 Injection in the OWASP Top 10, and you attach a CVSS score for severity. That triple, WSTG ID plus Top 10 category plus CVSS, is what a mature finding looks like.
Work the categories in order, mapping each test to a tool or manual technique, and log the WSTG ID against every result whether it passes or fails. Start with passive Information Gathering using search engines, whatweb, and Wappalyzer, then fingerprint the server and frameworks under CONF.
Move into the authenticated surface: enumerate users and test lockout under ATHN, hunt for IDOR and privilege escalation under ATHZ, and inspect cookies and fixation under SESS. The bulk of high-severity findings live in INPV, where you use Burp Suite Intruder, sqlmap for injection, and ffuf for content discovery. WSTG is the manual backbone, but pairing it with continuous, AI-driven coverage is the modern way to keep findings current between engagements, which is the core idea behind agentic pentesting.
Most WSTG tests have an obvious tool or manual technique behind them, and a small core kit covers the majority of the guide. Burp Suite is the hub for almost everything in INPV, SESS, ATHN, and ATHZ because it sits inline and lets you replay and fuzz requests.
For a fuller breakdown of when to reach for each, see our guide to web application penetration testing tools.