Overview

The OWASP Web Security Testing Guide (WSTG) is the premier cybersecurity testing resource for web application developers and security professionals. It is a comprehensive, community-driven methodology for performing penetration tests and security assessments of web applications and web services, maintained as an OWASP Flagship project.

Rather than a loose list of tips, WSTG provides a repeatable, structured framework: each individual test maps to a stable identifier (e.g. WSTG-INFO-02), so findings, reports, and tooling can reference an exact, versioned test that does not change meaning between releases. This makes it a de facto community standard adopted by pentesters, testers, and development teams worldwide.

The Web Security Testing Guide is the premier cybersecurity testing resource for web application developers and security professionals.

Test categories

The bulk of WSTG is organised into twelve top-level test categories, each with a four-character code prefix. The categories cover the full attack surface of a modern web application, from reconnaissance through business logic abuse to client-side and API weaknesses.

  • WSTG-INFO — Information Gathering: fingerprinting, mapping the application, and discovering exposed metadata
  • WSTG-CONF — Configuration and Deployment Management: server, platform, TLS, and infrastructure hardening checks
  • WSTG-IDNT — Identity Management: role definitions, registration, and account provisioning flaws
  • WSTG-ATHN — Authentication: credential handling, brute-force protection, and login logic
  • WSTG-ATHZ — Authorization: privilege escalation, IDOR, and access-control bypass
  • WSTG-SESS — Session Management: cookie attributes, fixation, and session lifecycle
  • WSTG-INPV — Input Validation: injection (SQL, XSS, command, etc.) and improper input handling
  • WSTG-ERRH — Error Handling: information leakage via error messages and stack traces
  • WSTG-CRYP — Weak Cryptography: transport security, weak ciphers, and padding/encryption flaws
  • WSTG-BUSL — Business Logic: abuse of legitimate workflows and process timing/integrity flaws
  • WSTG-CLNT — Client-side Testing: DOM-based XSS, CSP, clickjacking, and browser-side issues
  • WSTG-APIT — API Testing: REST/GraphQL and web-service-specific testing

Methodology & framework

WSTG frames testing as part of a Secure SDLC rather than a single end-of-project event. Its testing framework spans five phases: before development begins; during definition and design; during development; during deployment; and during maintenance and operations. Embedding tests across these phases shifts security left and reduces the cost of fixing defects.

The guide supports black-box (no internal knowledge), grey-box (partial knowledge), and white-box (full source and configuration access) approaches, letting teams choose the depth that fits the engagement. It complements other OWASP standards: the ASVS defines what security verification requirements an application should meet, the OWASP Top 10 highlights the most critical risk categories, and WSTG provides the concrete how-to for verifying them.

How it is used

  • As a penetration-testing methodology and checklist to ensure consistent, complete coverage across engagements
  • For scoping assessments, agreeing test coverage with clients, and writing statements of work
  • To build internal test plans and standardise reporting using stable WSTG IDs
  • As a training and onboarding resource for new security testers and developers
  • To map findings back to ASVS requirements and OWASP Top 10 categories for risk context

History

WSTG evolved from the OWASP Testing Guide, first published as v1 in 2004, followed by v2 (2007), v3 (2008), and the widely adopted v4 in 2014. The project was subsequently renamed the Web Security Testing Guide. Version 4.1 was released in April 2020, and the current stable release, version 4.2, followed on 3 December 2020, introducing new test scenarios and improved formatting alongside rolling updates on GitHub.

Development is now focused on version 5.0, worked on in the project's GitHub repository, which will refresh and expand the testing content. The latest in-progress material is always available from the repository, while v4.2 remains the recommended stable reference for production testing and reporting.

Resources