The WSTG repository builds the guide's website page, and the guide itself lives elsewhere

This is the website, not the testing guide

The first line of the README settles what the repository is. It contains the files that build the Web Security Testing Guide project's page on the main OWASP website, and the page itself is published at owasp.org/www-project-web-security-testing-guide/. The guide project produces the premier cybersecurity testing resource for web application developers and security professionals, and that resource has two homes. The prose, the test cases and the methodology live in the guide's own project repository at github.com/OWASP/wstg. The page that presents it, with its navigation, its downloads, its FAQ and its links to the current and archived versions, is built from the files in this repository. That split is easy to miss if you arrive from a search result for the guide itself, and it is the first thing to establish before touching anything here, because the two repositories have different rules and different review paths.

Contributions to the guide belong in the other repository

The contribution rules are unusually explicit, and the README repeats them in a caution block. Any contributions to the guide itself should be made via the guide's project repo, using a pull request, and no one outside the project leadership or foundation automation should be pushing directly to either repo. The caution adds that contributions should only be made in the proper repo against the latest content, and asks people not to open pull requests here for versioned or stable content, because those directories represent point-in-time state. That last clause is the important one for anyone tempted to fix a typo in an old version directory. The versioned trees are frozen snapshots of what a release said at a given moment, so a change there rewrites history rather than fixing the live page. There is also documentation explaining the files in this repository, hosted separately at owasp.org/migration, which is where the maintainers put the explanation of the site structure rather than in the README.

Local development is Jekyll, Bundler and a git clone

The Getting Started section is a four step recipe for running the site on your own machine, and it is short enough to follow exactly. First install Jekyll and its required dependencies for your operating system, following the Jekyll installation instructions. Then clone the repository, and then install the dependencies and serve the site. The clone, the dependency install and the local server are three commands:

`git clone [email protected]:OWASP/www-project-web-security-testing-guide.git www-wstg`

`cd www-wstg && bundle install`

`bundle exec jekyll serve`

The interesting detail is that the clone is done with an SSH remote rather than an https one, which means you need a GitHub key configured before the second step will work. The last command serves the site locally with the standard Jekyll server, so you can see the page as it will render. There is a Gemfile at the repository root for the dependency set, and a _config.yml for the site configuration.

The page is assembled from data files and includes

The top level of the repository is a Jekyll site, and its layout explains how the OWASP project pages are put together. There is the configuration file _config.yml, a _data/ directory for the structured content that drives the templates, an _includes/ directory for the reusable partials, and an assets/ directory for images and stylesheets. Then there are the content files, index.md for the page body, info.md for the project information, leaders.md for the project leadership list, tab_downloads.md and tab_faq.md for the two tabs the page offers, and a 404.html for the not found page. A project.owasp.yaml file holds the metadata that other OWASP tooling reads about the project. The versioning is visible as directories: latest/, stable/, and the point in time trees v41/ and v42/. That structure is the reason the caution about frozen content exists, and it is also the reason this repository is interesting to a web developer even if the guide itself is not their concern, since the same templates and data files are reused across the whole OWASP website.

What the guide project is, and what this page does for it

It is worth separating the two artefacts, because they serve different audiences and the page is what brings people to the guide in the first place. The Web Security Testing Guide is a testing resource for people who assess web applications, and it is maintained as a project with its own repository, its own pull requests and its own release process. The page here is the entry point on the OWASP website, and its job is to present that resource, point at the current version, offer the archived versions, and carry the practical information a reader needs before they clone anything. The downloads tab and the FAQ tab are part of that job. A reader who wants the methodology should follow the guide repository, and a reader who wants to know what the project is, who leads it, and where to get the current release, is served by this page. The value of the split is that a documentation change to the guide and a website change to its landing page do not block each other.

The alternative is the guide repository, and the difference is who reviews it

The realistic alternative is to work in the guide's own repository, or simply to read the published page and skip both. The difference in approach between the two repositories is mostly about review and release. Content written in the guide repository is reviewed by the people who own the technical content, and it flows into the guide's own versioning and releases. Content written here is reviewed by whoever maintains the OWASP website templates, and it changes the presentation rather than the guidance. The practical consequence for a contributor is that the question to ask first is not what to change but where the change belongs, and the README answers that question for you in a single sentence. If your change alters what a tester should do, it is guide content. If it alters how the project is presented, it is site content, and the migration documentation at owasp.org/migration is the place to check how the site files are arranged.

The site is current even though the guide has no releases here

The maintenance picture for this repository is simple. It is not archived and the last push was on 2026-10-15, so the site files are being worked on. There are no GitHub releases in this repository, which is expected, since the releases belong to the guide project rather than to the files that build its landing page. The licence field could not be classified by GitHub, so if you intend to reuse the templates or the assets beyond contributing to the page, that is a question for the OWASP project rather than something the README settles. The broader point is that this is a small, focused repository with an unusual division of responsibility, and the fastest way to work on it is to read the contribution rules first, because the rules are what keep the guide and its page in step.

Editorial conclusion

Adopt this repository if you want to work on the Web Security Testing Guide's presence on the OWASP site, its navigation, its downloads and FAQ tabs, or the versioned snapshots, since that is exactly what the files here build. Do not use it as the source of the testing guidance itself, because the guide content is written in the separate OWASP/wstg repository, and do not expect edits to the versioned directories to flow into the current content. Before you open a pull request, read the contribution rules in the README and the migration documentation, and confirm with the project leadership that your change belongs to the site rather than to the guide.

Frequently asked questions

Official sources

1. Issues
2. OWASP/www-project-web-security-testing-guide on GitHub
3. Project website
4. README