OWASP WSTG: the Web Security Testing Guide as a repository, not a PDF

What the WSTG repository is for, and who actually uses it

WSTG is a testing framework, not a tool. The README describes it as "a comprehensive guide to testing the security of web applications and web services," assembled by volunteers and used by penetration testers and organizations. That audience matters. If you are a pentester who has to justify why you spent three days on session handling, WSTG gives you a named test to point at. If you are an AppSec engineer writing a scope document, it gives you categories to divide work. If you are a developer looking for a library to import, you are in the wrong repository entirely. The project is an OWASP Flagship effort, and the repository is the source of the document itself: Markdown files under document/, plus checklists/, a template/ directory, and a website/ directory. That layout tells you what to expect. You clone it to read it, to translate it, or to propose a change, not to run it.

The WSTG-<category>-<number> identifier scheme and why versioned links matter

The most consequential design decision in the repository is the naming convention. Every test carries an identifier of the form WSTG-<category>-<number>, where the category is a four-character uppercase string and the number is zero-padded from 01 to 99. WSTG-INFO-02 is the second Information Gathering test. The README then adds a rule that most people skip: identifiers may change between versions, so documents and tools should cite WSTG-<version>-<category>-<number> instead, with the version tag stripped of punctuation. WSTG-v42-INFO-02 pins the test to release 4.2. The README states plainly that identifiers used without a version element should be assumed to refer to the latest content, and that this becomes problematic as the guide grows. The same logic applies to links: the project asks that you link to versioned URLs such as the v42 path rather than stable or latest, because those will change with time. This is a documentation project behaving like a versioned API, and it is the right call. It also means a report that cites bare WSTG-INFO-02 is ambiguous by design, and the ambiguity is the author's fault, not the project's.

Installing nothing: cloning the guide and reading the 5.0 draft

There is no package to install. The README points to the document directory on GitHub for the current 5.0 work and to release 4.2 for the last stable version, which is also published online. The practical first step is a clone, because that gives you the Markdown sources, the checklists, and the ability to diff your local copy against upstream later.

git clone https://github.com/OWASP/wstg.git
cd wstg
git checkout v4.2

After the checkout you are on the stable tag rather than the default branch, which matters: master holds the in-progress 5.0 content, and the README says the team is currently working on release version 5.0. If you only want to read, the repository is browsable on GitHub without cloning at all, and the README links to the v4.2 document online. The checklists/ directory is the part most teams actually use day to day, since it turns the prose into something you can tick through during an engagement, and the RELATED SEARCHES data suggests people look for exactly that: an OWASP WSTG checklist, and an Excel-friendly version of it. Nothing in the repository promises a spreadsheet export, so treat the checklist as the source and build your own tracking sheet around it.

Where WSTG stops being the right tool

WSTG is a guide, and guides do not execute. It will not find a SQL injection for you, it will not run in CI, and it will not produce a pass or fail. If your requirement is automated regression coverage on every pull request, WSTG is the wrong artifact and no amount of reading it changes that. There is a second, subtler limitation: the stable release is old. v4.2 shipped on 2020-12-03, and the only release since is the 20230928 prerelease. The README confirms 5.0 is still in progress. That gap is not neglect, since the last push to the repository was on 2026-09-18, but it does mean a team that pins to the stable tag is reading a document written before several years of web platform change. The third limitation is scope. WSTG covers web applications and web services. It is not an API security standard, not a cloud configuration benchmark, and not a threat model. Teams that treat it as a complete security program will find the gaps at the edges, not in the middle.

WSTG versus ASVS and the OWASP Top 10

These three get compared constantly, and the difference is in what each one is for. The OWASP Top 10 is a awareness document: ten risk categories, ranked, with no test procedures attached. It tells you what tends to go wrong. WSTG is a testing methodology: it tells you how to go and check, category by category, with numbered tests you can assign to a person and a timeslot. ASVS is a requirements standard: it gives verifiable application security requirements at defined levels, which is what you hand to a development team or an auditor who needs to assert that something is true. In practice a program often uses all three, and the failure mode is using one where another belongs. Asking a developer to "do the WSTG" produces a confused developer. Asking a pentester to verify ASVS Level 2 produces a pentester who has to map requirements onto tests manually, which is a real cost. WSTG is the execution layer of that stack, and it is strongest when it stays there.

Licence, translations and the real cost of staying current

The repository is licensed CC-BY-SA-4.0, and the README displays the Creative Commons badge. That is a content licence, not a software licence, and it has consequences worth understanding before you paste the guide into an internal wiki or a client deliverable. Share-alike means derivative works carry the same licence terms, and attribution is required. This is not legal advice, and the exact obligations depend on how you redistribute, but the practical question to answer early is whether your internal derivative is a distribution. On maintenance: the repository is not archived and the last push was on 2026-09-18, so the document is moving. The cost of that movement lands on anyone who cited identifiers, because the README explicitly warns that identifiers may change between versions. Upgrading from a 4.2-based report template to 5.0 content is therefore not a find-and-replace exercise. The README also lists community translations for Portuguese-BR, Russian, Persian, Turkish and Spanish, all hosted outside this repository, which means translation freshness tracks those separate maintainers rather than the upstream project.

Contributing back: what the project asks for

The README invites contributors and points to CONTRIBUTING.md rather than restating the process. The listed ways to help are concrete: fix spelling and grammar in the current content, help with translation, pick an existing issue and open a pull request, or open a new issue to report an improvement opportunity. Contributors who land changes appear on the project's list of authors, reviewers or editors under document/1-About/. Coordination happens in the OWASP Slack channel #testing-guide, on X at @owasp_wstg, and in the project's Google Group. If you are evaluating WSTG for adoption and you find a gap that matters to your team, that is the path to closing it. The repository is not a product with a roadmap you can buy into; it is a document that changes when someone writes the change.

Editorial conclusion

Adopt WSTG if you need a shared vocabulary for web application testing and can live with a document that is still being rewritten for 5.0. Do not adopt it as an automated scanner, a compliance certificate, or a substitute for ASVS when you need verifiable requirements. Before you cite anything in a report, open the identifier rules in the README and decide whether you are quoting WSTG-v42-* or the unreleased master branch, because the two are not the same document and the identifiers can move between them.

Frequently asked questions

Official sources

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