Versioned IDs, unpinned links, and a stable release that is six years behind the working document

Scenario identifiers are only stable if you carry the version yourself

Every scenario carries an identifier in the shape `WSTG-<category>-<number>`, where the category is a four character upper case string naming the type of test or weakness and the number is a zero-padded value running from 01 to 99. `WSTG-INFO-02` reads as the second Information Gathering test. The catch is stated in the same place: identifiers may change between versions, so the project asks other documents, reports, and tools to use `WSTG-<version>-<category>-<number>` instead, with `WSTG-v42-INFO-02` meaning the second Information Gathering test from version 4.2. An identifier written without the version element is to be assumed to refer to the latest content. That assumption is where a finding starts to rot. The same string can name different content once the guide grows, and the string itself carries no evidence of which text you read, so the sentence in your report names a test whose content may have been rewritten underneath it.

stable and latest move, while v42 paths are meant not to

Linking guidance here is specific about URL shape. Links should be built with versioned paths rather than `stable` or `latest`, because those two change with time, and it is the stated intention of the project team that versioned links do not change. The full pattern puts the version token inside the site path, followed by the section and test directories:

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.html

In that example the `v42` element refers to version 4.2. What the convention buys you is a citation that resolves to the same text years later, which is the entire reason the guide pushes back against the friendly short links. What it costs you is a long URL that reads like a mistake to anyone skimming your appendix, and a hard dependency on a filename convention, padded two digit numbers and underscores between words included, that the published site has to keep honoring.

The stable tag is 4.2 while the working document is 5.0

Two versions coexist in this repository and they are not interchangeable. The project states that it is working on release version 5.0, with the current document to be read on GitHub under the master branch, while the last stable release is 4.2, dated 3 December 2020, preceded by a 4.1 release on 21 April 2020. The newest tag in the release list is a prerelease dated 28 September 2023, and the last push to the repository landed on 1 November 2026. The gap a reader inherits is years wide: what you find under the document directory on master is not what a v42 link resolves to, and a team that cites 4.2 is citing text that predates most of the writing in progress. The README gives no target date for the 5.0 tag, so a plan that depends on 5.0 needs a date obtained from the project rather than from the release list.

The published path exposes how sections and tests are numbered

The online URL is the most direct statement of internal structure available without opening the document tree. A scenario URL is a section directory carrying a two digit index, then a category directory carrying a two digit index, then the test file. In the example the project supplies, `4-Web_Application_Security_Testing` contains `01-Information_Gathering`, which contains `02-Fingerprint_Web_Server.html`. That lines up with the identifier rule: category codes are four upper case characters, so INFO is a code rather than the spelled out category title, and the numeric part runs 01 to 99. For tooling, anyone writing a converter between a checklist and an internal harness has to reproduce this naming exactly, including the zero padding, because the padding is part of the name and not a display choice.

Translations are five separate repositories with no version lock

The translated editions are not folders inside this repository. Portuguese-BR, Russian, Persian (Farsi), Turkish, and Spanish each live in their own repository under their own maintainer, and one of the links points at a subdirectory inside a differently named repository. That layout has a direct cost: nothing here guarantees that a translation sits on the same version as the English text, and the version token that makes your English citations verifiable has no enforcement mechanism across those forks. For a reader working in one of those languages, the move is to check a translation's version marker before relying on a scenario, and to fall back to the English identifier format when you need an unambiguous reference. The project does point newcomers at the translation section of its contribution guide for anyone willing to help close that gap.

The contribution path starts with typos and existing issues

Contribution guidance is concrete about the order of work. First time contributors are pointed at GitHub's own first-time contributor suggestions for the repository, and the contribution guide at the repository root is the document to read before anything else. Four ways to help are then named that do not require deep security work: read the current content and fix spelling mistakes or grammatical errors, help with translation, choose an existing issue and submit a pull request to fix it, or open a new issue to report an opportunity for improvement. Credit lands on the project's list of authors, reviewers, and editors, which is kept inside the document tree at document/1-About/README.md. Around that sit a code of conduct, a security file, a style guide, and directories for templates, the website, and checklists.

Nothing in the repository executes a test for you

This is a document project, and that boundary decides who the guide is for. What the project describes itself as is a framework of best practices used by penetration testers and organizations, built by security professionals and volunteers. The repository listing at the top level is document/, checklists/, template/, and website/, alongside editing and governance files, and its language statistics report Python as primary, so the tracked output is the prose and the material around it, not an executable harness. Nothing in that listing touches the application under review. Two consequences. Coverage is a function of the person doing the work, so an unexecuted scenario in a checklist is indistinguishable from a passing one unless you keep your own evidence and dates. And if you need automation, this project hands you stable identifiers to key your tooling on, and stops there.

Editorial conclusion

The fit is a team that wants one agreed vocabulary for web and service security testing and is willing to keep the version token inside its citations; it is the wrong tool for anyone expecting a scanner or for current content on demand. Before building on it, check which version your readers actually have, whether the 5.0 work has been tagged since, and whether the translation you rely on carries the same version marker.

Frequently asked questions

Official sources

1. License: CC-BY-SA-4.0
2. OWASP/wstg on GitHub
3. Project website
4. README
5. Releases