OWASP WSTG Guide: Structure, Test IDs and Using It in Test Plans

Most web application test plans say they "follow the OWASP Testing Guide" without saying which version, which tests, or what was left out, so nobody can tell what was actually tested. The OWASP Web Security Testing Guide (WSTG) is the reference methodology for testing web applications and web services, and it is built to be referenced test by test. This guide explains how the WSTG is organised, how its test identifiers work and change between versions, how version 4.2 and the version 5.0 work in progress differ, and how to turn the guide into a scoped, repeatable test plan and report. It is written for application security leads, penetration testers, QA engineers and the people who commission and review web tests.

Key takeaways

• The WSTG is a methodology, not a standard. OWASP describes it as a framework and technique reference to adapt to your threat model, not a rigid checklist or a compliance standard. Pair it with OWASP ASVS when you need pass or fail requirements.
• Version 4.2 is the last stable release. The project's GitHub repository states that release 5.0 is being worked on, and the content on the master branch already renames categories and test IDs.
• Always cite versioned IDs. The project asks for the form WSTG-v42-INFO-02, because unversioned IDs refer to the latest content and can change meaning.
• Scope by category, then by test. A test plan should list every WSTG test as in scope, out of scope (with a reason) or not applicable, so coverage gaps are explicit rather than silent.
• The guide reaches well beyond the pentest. Its testing framework covers requirements review, threat modelling, code review, CI pipeline checks and continuous testing, each with its own cadence and owner.

What the WSTG is and what it is not

The WSTG is an open source, community maintained OWASP flagship project that describes how to test the security of web applications and web services. Its introduction on the master branch states plainly that it is not a rigid checklist or compliance standard but a methodology and technique reference. That distinction matters when you write contracts and test plans: the WSTG tells a tester how to test for a weakness, while the OWASP Application Security Verification Standard tells a developer what the application must do. The OWASP Top 10 is an awareness list of risk categories, not a test method. See the OWASP Top 10 Guide.

The WSTG also places testing in a wider programme. Its testing framework chapter describes six activity families that recur on a cadence rather than in a fixed sequence: requirements and policy review, design and architecture review with threat modelling, code-level review and analysis (SAST, secret scanning and SCA), dynamic and penetration testing, CI pipeline testing, and continuous and crowd-sourced testing such as bug bounty programmes. It is explicit that a finding in one activity should feed back into others, for example a business logic flaw found in a pentest becoming a missing control in the threat model. See the Web Application Security Testing Guide for how these activities fit together across tools.

How the guide is structured

The document has five main parts: an introduction, the OWASP testing framework, the web application security testing chapter (section 4, which holds the actual test cases), a reporting chapter, and appendices covering tools, suggested reading, fuzzing, encoded injection, browser developer tools and other penetration testing methodologies. Each test case follows the same layout: an ID table, a summary, test objectives, how to test, remediation where given, tools and references. The "Test Objectives" bullets are the most useful part for planning, because they are short, outcome-based statements you can lift into a test plan as acceptance criteria for the test itself.

Test categories in v4.2 and on the master branch

Section 4 is split into categories, each with a four-letter code. The v4.2 release and the current master branch (the version 5.0 work in progress) use mostly the same codes, but several category names were shortened and the input validation category was renamed.

The master branch has also added material that v4.2 did not have, including tests for path confusion, other security header misconfigurations, feature flag bypass, concurrent sessions, prototype pollution, insecure deserialisation, client-side template injection and a fuller API testing category, plus framework sections on bug bounty programmes and human-AI collaborative testing. Treat master content as draft: it is useful for ideas, but cite v4.2 in contracts until 5.0 is released.

Test identifiers and versioning

Each test has an ID in the form WSTG-<category>-<number>, where the category is the four-letter code and the number is a zero-padded value from 01 to 99. The project README warns that identifiers may change between versions and asks that documents, reports and tools use the versioned form WSTG-<version>-<category>-<number>, for example WSTG-v42-INFO-02 for the second information gathering test in version 4.2. Unversioned IDs are assumed to mean the latest content. It also asks for versioned links (the /v42/ path on owasp.org) rather than "stable" or "latest" links.

The change is not theoretical. GraphQL testing is WSTG-APIT-01 in v4.2 but WSTG-APIT-99 on the master branch, where APIT-01 to APIT-04 now cover API reconnaissance, broken object level authorisation, excessive data exposure and broken function level authorisation. SQL injection is WSTG-INPV-05 in v4.2, while the injection tests on master carry the INJT prefix. A tracker that stored bare IDs would silently re-label findings after an upgrade.

• Store the version with every ID: in the test plan, the finding record, the ticket and any tool mapping (for example a DAST rule to WSTG mapping table).
• Map once per upgrade: when 5.0 is released, build a v42 to v5 crosswalk for the tests you use and re-baseline coverage, instead of renaming history.
• Keep the test objective text: copy the objective bullets into your plan so a later reader knows what "WSTG-v42-ATHZ-04 passed" actually meant.

Building a test plan from the WSTG

A good WSTG-based plan is a coverage matrix, not a narrative. Every test in the chosen version gets a row and a status, and the plan explains anything that is not tested. The steps below work for internal teams and for commissioning a third party.

1. Fix the version and scope: name the WSTG version (v4.2 unless agreed otherwise), the applications, hostnames, API base paths and environments, and the test window. The penetration test scoping work belongs here; see the Penetration Test Scoping Checklist.
2. Gather design inputs: architecture diagrams, the threat model, the OpenAPI or GraphQL schema, role and permission matrices, and the ASVS level the application targets. The WSTG framework chapter treats these as test inputs, not optional extras.
3. Set the test perspective: decide black-box, grey-box or white-box, and supply at least two accounts per role. The v4.2 IDOR test (WSTG-v42-ATHZ-04) says the best way to test is with at least two, often more, users who own different objects, plus users with different privileges.
4. Mark every test: in scope, out of scope with a reason (for example "no file upload feature"), or not applicable. Give business logic (BUSL) and authorisation (ATHZ) tests explicit time, because automated tools rarely cover them.
5. Map tooling to tests: record which tests a DAST scan, SAST rule set or manual review will cover. Anything without a mapping needs manual effort or is a declared gap.
6. Agree rules of engagement: rate limits, data handling, production versus staging, notification contacts for critical findings and a stop condition if testing affects service.
7. Define the reporting format: severity scale, whether CVSS is required, retest window and the evidence expected per finding (see below).
8. Retest and close: retest fixed findings against the same WSTG IDs and record the result, so the coverage matrix shows both what was tested and what was fixed.

Tailoring by application type

For APIs, combine the WSTG API category with the OWASP API Security Top 10 2023 risk list (API1 Broken Object Level Authorization and API5 Broken Function Level Authorization map directly to the master branch APIT-02 and APIT-04 tests). See the API Penetration Testing Guide.

Where identity fits

Four of the WSTG categories are about identity: IDNT, ATHN, ATHZ and SESS. In practice they produce many of the highest impact web findings: default credentials, weak reset flows, IDOR, missing function level checks and long-lived tokens. Two points are easy to miss. First, the test accounts and API keys issued to testers are themselves non-human credentials: issue them for the test window only, scope them to the test tenant, log their use and revoke them at the end. Second, OAuth and JWT tests (ATHZ-05 and SESS-10 on the master branch) should cover service clients and machine tokens as well as user sessions, because integrations often hold broader scopes than people. See the JWT Security Guide and the Business Logic Vulnerabilities Guide.

Reporting findings the WSTG way

The WSTG reporting chapter is offered as one possible approach, best suited to consultancy reports, and says it may be overkill for internal or bug bounty reports. Its structure is still a good default: an introduction (version control, team, scope, limitations, timeline, disclaimer), an executive summary in business terms, and findings with a summary table and detailed entries. Each detailed finding should carry a reference ID, a title, likelihood or exploitability, impact, a risk rating, a description, remediation steps and supporting resources, with sensitive data masked. It suggests Informational, Low, Medium, High and Critical as risk values, documented in an appendix, and notes that CVSS is sometimes required and sometimes just adds complexity.

• Add the versioned WSTG ID to every finding so retests and trend reports line up.
• Attach reproducible artefacts: the master branch reporting chapter lists request examples, HAR files and simple automation scripts that help developers verify fixes. Redact tokens and personal data from them.
• Report human factors: the same chapter asks testers to report user-facing and process weaknesses such as account enumeration through error text, weak recovery flows and help desk processes, not just technical bugs.
• Attach the coverage matrix: the reporting chapter suggests including a checklist of all tests conducted; the WSTG project publishes checklists in its GitHub repository.
• Encrypt the report: the chapter advises securing and encrypting the report so only the receiving party can use it.

Severity and fix deadlines should follow your own bug bar rather than the tester's labels. See the Vulnerability Severity and Bug Bar Guide for Development Teams and the CVSS v4 Guide.

Using AI tools within a WSTG engagement

The master branch adds a section on human-AI collaborative testing. It is careful about scope: it covers testing with AI tools, not testing of AI systems, which it leaves to the OWASP AI Testing Guide and the OWASP Top 10 for LLM Applications. It accepts that AI tools now speed up candidate payload generation, response triage, multi-step orchestration and report drafting, while holding that scope, rules of engagement, validation and the decision to report stay with a human. It lists the risks to plan for: false positives and hallucinated findings, over-trusting automated severity scores, prompt injection from application responses that a tool ingests, opaque tools that cannot explain a finding, and bug bounty programme rules on AI-generated reports. Write these into the rules of engagement: which AI tools may be used, what target data they may send to an external model, and that every AI-suggested finding is validated by hand before it is reported. See the AI-Assisted and Autonomous Penetration Testing Guide.

Measuring a WSTG-based testing programme

• Declared coverage: percentage of WSTG tests marked tested, out of scope with reason, or not applicable, per application. Aim for no unmarked tests.
• Manual category coverage: share of ATHZ and BUSL tests executed manually rather than inferred from a scanner, per release.
• Findings by category over time: recurring ATHZ or SESS findings across releases point to a missing shared control rather than individual bugs.
• Retest pass rate: findings that pass first retest, by severity. A low rate usually means remediation advice was too vague.
• Escapes: issues later found by bug bounty, incident or customer report that fall in a WSTG category marked "tested". Each escape should update the plan or the test method.

Framework mapping

Common failure patterns

• "Tested against OWASP" with no version or test list: nobody can tell what was covered, and a later reviewer cannot compare two reports. Fix: versioned IDs and a full coverage matrix.
• Scanner output relabelled as a WSTG test: DAST tools cover parts of INFO, CONF, INJT and CRYP well, but rarely business logic or multi-user authorisation. Fix: map tools to tests explicitly and leave the rest for manual work.
• One test account: IDOR and privilege escalation cannot be tested properly with a single user. Fix: two or more accounts per role, and cross-tenant accounts for SaaS.
• Using the Top 10 as the scope: ten categories leave whole WSTG areas, such as session management detail and client-side tests, unplanned. See the OWASP Top 10 Guide for what the list is meant for.
• Citing master branch IDs in contracts: IDs on master can still change before release. Fix: contract on v4.2, use master content for ideas.
• Leaving tester credentials live: accounts and API keys created for the test survive the engagement. Fix: expiry dates, logging and a revocation step in the close-out.

Practitioner checklist

• State the WSTG version in every test plan, contract and report, and use the WSTG-v42-XXXX-NN ID form.
• Build a coverage matrix with every test marked in scope, out of scope with reason, or not applicable.
• Provide architecture, threat model, API schema and role matrix to testers before the test starts.
• Supply at least two accounts per role, and cross-tenant accounts where the application is multi-tenant.
• Reserve manual time for ATHZ, BUSL and APIT tests, and map automated tools to the tests they really cover.
• Pair the WSTG with an ASVS level so test results map to agreed requirements.
• Require findings with versioned IDs, risk rating rationale, masked evidence and reproducible artefacts.
• Write AI tool use, data handling and human validation into the rules of engagement.
• Issue tester credentials with an expiry and revoke them at close-out.
• Plan a v4.2 to v5 crosswalk for the tests you use when version 5.0 is released.

Standards and references

• OWASP: Web Security Testing Guide project
• OWASP: Web Security Testing Guide v4.2
• OWASP: WSTG GitHub repository (version 5.0 work in progress)
• OWASP: WSTG checklists
• OWASP: Application Security Verification Standard 5.0
• OWASP: API Security Top 10 2023
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Web Application Security Testing Guide · OWASP ASVS Guide · Penetration Testing Guide · API Security Guide