OWASP API Security Top 10: a document project, not a scanner

Two deliverables, stated as aims rather than features

The README describes the project's purpose before it describes anything else, and the framing is worth keeping in mind because it explains what kind of repository this is. It is designed to address the growing number of organisations deploying potentially sensitive APIs, both for internal tasks and for interfacing with third parties, many of which do not undergo the rigorous security testing that would make them secure.

The solution offered is not a product. The project states three aims: create the OWASP Top Ten API Security Risks document, create a documentation portal for developers building APIs securely, and work with the security community to maintain living documents that evolve with security trends.

There is also a claim of prior art worth noticing, because it is a fairly strong one. The README says there are resources to help create and evaluate such projects, naming the OWASP REST Security Cheat Sheet specifically, but that there has not been a comprehensive security project for builders, breakers and defenders. That framing is why the project has a CNCF-style council structure and three named project leaders rather than a single maintainer.

The project leaders are listed by name with links to their OWASP user pages, except the third, Paulo Silva, whose entry is a mailto link rather than a profile URL. Small detail, but it is the kind of inconsistency that appears in real projects rather than curated ones.

GitHub reports no license, the README specifies CC BY-SA 4.0

The licensing here is stated unusually clearly in the README and then not picked up by GitHub's classifier. The README has a Licensing section saying the OWASP API Security Project documents are free to use, licensed under the Creative Commons Attribution-ShareAlike 4.0 license, with the plain-language explanation: you can copy, distribute and transmit the work, you can adapt it and use it commercially as long as you attribute the work, and if you alter or build upon it you may distribute the result only under the same or similar license.

GitHub reports the repository's license field as NOASSERTION, its way of saying it could not classify the terms from the files. A LICENSE file is present in the tree, so the material is there; the classifier simply did not recognise it, which is unsurprising for a Creative Commons document rather than an OSI-style software license.

Both facts are worth holding at once and neither invalidates the other. The share-alike clause is the part that matters for reuse and it is stated explicitly rather than buried: adapt it freely for internal documentation, but if you publish a modified version you owe attribution and the same license. That is a different bargain from the permissive licenses most code carries, and for a document you intend to copy into your own internal security guidance, that is the clause to notice.

A MkDocs site with a plugin installed from a feature branch

The whole site is a documentation project, and the build is visible in the repository's two infrastructure files. The compose file mounts the docs directory read-only into a preview service on port 8000:

services:
  preview:
    build: .
    image: owasp/api-top10:latest
    container_name: "owasp_api-top10"
    ports:
      - "8000:8000"
    volumes:
      - .:/docs:ro

That is the entire local preview setup: one service, one port, one read-only mount. There is no build step in the compose file because the image does the building.

The Dockerfile is three instructions and one of them is unusual. It starts from a pinned MkDocs Material image, then installs a plugin directly from GitHub, on a branch that is not the repository's default:

FROM squidfunk/mkdocs-material:9.0.9

ENV MKDOCS_MONOREPO_REPO=https://github.com/PauloASilva/mkdocs-monorepo-plugin
ENV MKDOCS_MONOREPO_BRANCH="feat/i18n"

The follow-on line installs that plugin plus pymdown-extensions. Pinning the base image to a specific version is good practice for reproducibility. Pinning the plugin to a feature branch under one maintainer's personal fork is the opposite, and it means the site's build depends on a branch that can change or disappear without any change in this repository. If you are reading this project as a template for your own documentation, that is the line to fix first.

The `MKDOCS_MONOREPO` naming suggests why the plugin exists: maintaining several language editions of the same content from one source, which is the only sensible approach once you have more than one translation.

An editions directory and a VERSION file that the README never mentions

The repository tree is short and structured: `docs/` for the site content, `editions/` for the per-language and per-version outputs, `mkdocs.yml` for the site configuration, `CONTRIBUTING.md`, `SECURITY.md`, `LICENSE`, `Dockerfile` and `docker-compose.yml`, plus a `VERSION` file at the root.

Two of those deserve comment. The `editions/` directory is how a single-source, many-translation documentation project keeps generated outputs separate from hand-written source, and it is why the i18n plugin is needed at all. And the `VERSION` file is the one artifact a reader would most want explained, because it presumably records which edition of the Top 10 this checkout corresponds to, and the README says nothing about it.

The README does point at a PDF at a path that includes a year and a language, which tells you editions are versioned by year and translated, and at a `develop` branch reference for the tree listing while the repository's default branch is `master`. So there are at least two long-lived branches with different roles, which is a normal pattern for a project that has shipped multiple editions.

There are no tagged releases in what is visible here, which is the expected shape for a document project. Versioning happens through the Top 10 edition itself, the 2023 edition being the current widely referenced one, rather than through release tags on the repository.

Fifteen open issues for a project this size

The repository has 2368 stars, 423 forks and 15 open issues. For a documentation project that ratio is unusual in a good way, and it says something about how the contribution model works.

The README contains no request for help, no good-first-issue list and no maintainer response time. It points to the OWASP project page, the contribution guide and the three project leaders. For a document rather than a program, that is arguably the right amount of process: substantive proposals go through the contribution guide, translations are handled by translators, and the leaders named in the README are the escalation path.

The last recorded push is dated 2026-09-22, and the repository is not archived. GitHub reports the language as Dockerfile, which is an artefact of the repository having almost no source code in the conventional sense and reflects the three-line Dockerfile being the largest coherent unit of content it can classify. The topic list is correspondingly documentation-shaped: `api`, `documentation-portal`, `owasp-top`, `security` and `web-api`.

What a reader should take from all this is that the value of the repository is the quality and currency of the risk list, and that is judged by reading the document rather than by reading the code. There is very little code here, and the small amount there is could mostly be tightened.

Editorial conclusion

This repository exists to produce two things, a Top 10 risks document and a documentation portal, and everything in it serves one of those. There is no scanner here and nothing to deploy; if you are looking for a tool to test your API, this is the wrong repository. What it gives you is an agreed vocabulary for API risk that a developer, an assessor and a security team can all point at, which is a harder thing to produce than it sounds. Start at the documentation portal rather than the PDF, because the portal is where the current edition lives and where the mitigation guidance is maintained. Read the list once end to end before adopting it as a checklist, then check your language edition exists before citing it.

Frequently asked questions

Official sources

1. Issues
2. OWASP/API-Security on GitHub
3. Project website
4. README