# The W3C webappsec repository is a maturity tracker for browser security specs
> w3c/webappsec is the working group repository behind Content Security Policy, Subresource Integrity, Referrer Policy, Permissions API and a dozen other web security specifications, and its main artefact is a table that sorts every specification by maturity stage. It is not a library, it publishes no releases, and it carries a custom licence rather than a standard open source one.
**w3c/webappsec** — Web Application Security Working Group repo
- Repository: https://github.com/w3c/webappsec
- Website: https://www.w3.org/groups/wg/webappsec/
- Stars: 675 · Forks: 168
- Language: HTML
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/w3c-webappsec
## A working group home, not a code dependency
The repository is the Web Application Security Working Group's home, and its README is essentially a link directory. The top of the file lists the mailing list archive at lists.w3.org, the group's website at w3.org/groups/wg/webappsec, a tracker, and a Bugzilla instance that the README marks as deprecated in 2019. Everything else in the README is one large HTML table titled Table of Specifications. The repository root reinforces that this is a standards workspace rather than a distribution: `specs/` for the specification sources, `meetings/` for the group minutes, `admin/` for group administration, `usecases/` for the use cases that motivate the work, `implementation_reports/` for what implementations do, `polyfills/` for code that fills gaps, `mitigation-guidance/` for advice to deployers, `demos/` for demonstrations, and `unofficial-drafts/` for material that has not entered the group process. There is no package, no build step for consumers and no version to depend on.
## Every specification is sorted into a maturity bucket
The table is grouped into four row groups with named headings, and each entry gives an Editor's Draft link and a Technical Report link. The Complete group holds Content Security Policy Level 1, marked as a NOTE, and Subresource Integrity, marked REC, plus CSP Level 2, also REC. The three rows of the table look like this in the source:
```html
| Content Security Policy Level 1 |
|
NOTE: /TR/CSP1 |
```
The Stable group contains Mixed Content, Upgrade Insecure Requests, Secure Contexts and Referrer Policy, with a mix of CR and WD statuses. The Stabilizing group holds Credential Management Level 1 at WD, the Permissions API at FPWD, and Content Security Policy Level 3 at WD. The Works in Progress group lists Clear Site Data at FPWD, a Well-Known URL for Changing Passwords with no Technical Report link, and a document on detecting the reliability of HTTP status codes. The final group is Obsolete or Abandoned. Reading the status column is the fastest way to answer the only question most engineers have about a web specification, which is whether to write code against it yet.
## Content Security Policy appears three times with three different statuses
The table is worth reading closely because the same family of documents shows up in several stages at once. CSP Level 1 sits in Complete with a NOTE, CSP Level 2 is a REC, and CSP Level 3 is in Stabilizing at WD. That spread is the actual state of the art: the first level is finished, the second is a Recommendation, and the third is still a working draft, so a project that wants a policy that will not change should target Level 2 while the Level 3 features, such as the newer directive surface, remain subject to change. Two rows in the table also show small inconsistencies worth knowing about if you script against the index. The CSP Level 3 row links to an Editor's Draft at the same path as CSP Level 2, and the row for detecting the reliability of HTTP status codes points at a path inside the change password URL repository, both of which suggest the index is maintained by hand rather than generated from a machine readable manifest.
## Abandoned work stays in the table on purpose
The Obsolete or Abandoned group is the part of the index that most readers skip and engineers most need. It lists Confinement with Origin Web Labels, better known as COWL, at FPWD, CSP Pinning at FPWD, and Entry Point Regulation at FPWD. Each of these was a security mechanism proposal that did not progress to a finished Technical Report. CSP Pinning in particular still has an Editor's Draft published as a subpath of the CSP repository, which shows how easily a proposal can sit unfinished without being marked as failed. Keeping these rows visible is a deliberate piece of institutional memory: a new proposal in this space will often be a variant of something on this list, and the reason the earlier attempt stopped is rarely obvious from the abandoned draft alone. The directory names at the root support the same purpose, with `implementation_reports/` and `mitigation-guidance/` recording what was actually built and what deployers were told to do.
## The most immediately useful directories are not the specifications
For an engineer with a deadline, three directories in the repository root matter more than the specs themselves. `mitigation-guidance/` exists to tell deployers what to do about a weakness when there is no complete specification to wait for, which is the practical answer to a question the group gets asked often. `polyfills/` holds code that lets a page use a newer security feature on an older browser, which changes the deploy decision for a specification from no to yes. `implementation_reports/` records what browser vendors actually shipped, and it is the check to run before relying on a status of FPWD or WD, since a working draft tells you about the committee's intent and an implementation report tells you about your users' browsers. The `usecases/` directory explains the problems the group set out to solve, which is useful background but rarely the first thing an implementer opens.
## No releases, a custom licence, and a recent push
The repository has no GitHub releases, which is expected for a standards workspace where the artefacts are the published Technical Reports rather than tagged builds, and the last push to the repository was on 2026-10-13 with the repository not archived. The licence is recorded as a custom licence that GitHub cannot classify, with the details in LICENSE.md, and the repository also carries CODE_OF_CONDUCT.md and CONTRIBUTING.md. That licence situation is normal for a W3C group repository, but it means you should read LICENSE.md before copying text or code out of `specs/` or `polyfills/` into a product, and the polyfills in particular are the part most likely to be copied. The working group model also means the group can be closed or rechartered, so anything you depend on should be tracked against the published specification rather than against this repository.
## Conclusion
Engineers who need to know which version of a web security specification is safe to build on will find the maturity table in this repository the fastest single view, and the polyfills, mitigation guidance and implementation report directories the practical follow-up. It is the wrong artefact for a deployment decision on its own, because a specification stage says nothing about browser support, and the repository is not a library you can depend on. Before citing any of these documents, check the status column for the particular specification, read the implementation reports directory for what browsers actually shipped, and consult the polyfills directory if you need a fallback for an older browser.
## FAQ
### What is the w3c/webappsec repository used for?
It is the working group repository for web application security, and its main artefact is a table of specifications that sorts each document by maturity stage, from Complete and Stable through Stabilizing and Works in Progress to Obsolete or Abandoned. The root also holds spec sources, polyfills, mitigation guidance, implementation reports and meeting material.
### How do I know if a web security specification is ready to use?
The status column in the specifications table gives the answer, using the Technical Report states recorded there, such as REC for a Recommendation, CR for a Candidate Recommendation, WD for a Working Draft and FPWD for a First Public Working Draft. A status of REC means finished, while WD and FPWD rows are still subject to change.
### What happened to COWL and CSP Pinning?
Both appear in the Obsolete or Abandoned group of the table. Confinement with Origin Web Labels and CSP Pinning are listed there with FPWD status on their Technical Reports, alongside Entry Point Regulation, and the group keeps them visible as a record of proposals that did not proceed.
### Are there polyfills for the security features in this repository?
The repository root includes a polyfills directory, and the mitigation-guidance directory holds advice for deployers. Neither the README nor the table describes individual polyfills, so the directory listing and the group's documentation are the places to look for a specific fallback.
## Sources
- [Issues](https://github.com/w3c/webappsec/issues)
- [Project website](https://www.w3.org/groups/wg/webappsec/)
- [README](https://github.com/w3c/webappsec/blob/main/README.md)
- [w3c/webappsec on GitHub](https://github.com/w3c/webappsec)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/w3c-webappsec