webhacklist: a durable archive of every Top 10 Web Hacking Techniques nominee

The list is only the winners, the archive keeps the rest

The Top 10 Web Hacking Techniques has been running every year since 2006, with the community nominating research, voting, and crowning ten winners. The list was started by Jeremiah Grossman and is continued today by James Kettle at PortSwigger. What the webhacklist repository preserves is wider than the famous ten. It holds every nominated technique for every year, in one Markdown file per annual collection, with the combined 2016/17 collection counted as one. The record totals 1,136 original nomination entries plus 647 later additions, which is 1,783 records across 19 finalized collections. Those counts are list records rather than unique documents, which is a distinction the project is careful about, and the automation reads a publishing registry at website/archive-years.json. The practical value of that is that you can ask what was nominated in a given year and get an answer, rather than only learning about the ten techniques that happened to win.

A fixed layout, so the archive stays greppable

Every year file follows one layout, which is what makes a two-decade archive usable rather than a pile of documents. The file opens with a Top 10 section holding the ten techniques that won, in finishing order, each tagged with its rank, and everything else nominated that year follows under an Other nominations section, unranked and in its original order. The project states the format rules precisely: one bullet per technique, no trailing backslashes and no blank lines inside the lists. A winning entry looks like this:

## Top 10

-   [Blind SSTI](https://github.com/vladko312/Research_Successful_Errors) **#1**
-   [ORM Leaking More Than You Joined For](https://www.elttam.com/blog/leaking-more-than-you-joined-for/) **#2**

The consistency matters because it means a tool, a script or a person can walk all nineteen files the same way. The project also flags a subtlety in the ranks: they come from the announcement posts, but the entry text stays as the nominee list had it, so a winner's title in the results post is sometimes shorter or worded differently from its nomination. The long tail under Other nominations is described as where the genuinely novel work often hides, and that is the part of the archive most lists throw away.

Dead hosts are the reason the archive exists

The stated motivation is preservation, and it is a specific kind of decay. The annual announcement posts have a habit of disappearing, and the project names a casualty: the WhiteHat Security blog, home of the 2011 to 2015 lists, is already gone. The repository is meant to be a durable, greppable place for the whole record, and the tip offered for the years where the original post survives is the Wayback Machine, which the project says preserves most of the dead URLs. What it adds on top of that is a PDF archive of the announcement pages themselves, captured with reproducible tooling and with recorded provenance. The capture pipeline lives in the tools directory, with a Python script that drives headless Chrome and verifies the result, a sources.json manifest describing what to capture and from where with assertions attached, and a capture-report.json provenance log of the last run. The provenance is the part that matters for an archive, because a snapshot without a record of how it was taken is just a file.

PDF snapshots, per-year index and the capture tooling

The layout of the repository shows how the pieces fit. The annual Markdown collections sit at the root, one file per year, alongside a file for AI-collected candidates for a year that has no vote yet, which is kept deliberately separate from the curated lists. The original-listings directory holds the PDF snapshots, with a nominee list and a winners post per year plus a README that serves as the per-year index, the notes and the archive rationale. The website directory holds the production progressive archive site, with the publishing registry and a data directory containing a small catalogue plus one JSON shard per collection. The tools directory holds the capture pipeline, and the assets directory holds the logo and artwork. The README describes the site as searchable, with the ability to filter by year and open any preserved document without leaving the browser, and a live archive is published at webhacklist.com. The project describes itself as the complete archive of the top ten techniques, the complete archive, the complete archive, with the emphasis on completeness.

Research held out of the vote is recorded, not erased

Four years had research kept out of the competition to avoid a conflict of interest, and the archive keeps those entries visible instead of letting them disappear. They sit at the top of the Other nominations section in the relevant year file, each tagged with the stage it was held out of, with a note explaining what happened. The stages differed between years, so the wording does too. The 2016/17 collection holds out Cracking the Lens and XSS without HTML, because PortSwigger research was excluded up front, and by the time a recusal system replaced that rule it was too late to reintroduce it, so it never even reached the nominee list. The 2019 collection holds out HTTP Desync Attacks, which won the community vote outright, because James Kettle declined to rank his own research first. The 2024 collection holds out further entries, and the README notes that the stages were not the same. This is a level of bookkeeping that most archives skip, and it is what separates a record of what was published from a record of what happened.

Later additions are separated from the original nominations

The project is careful about the difference between the historical record and its own editorial work, and this is the part that decides whether you can cite it. The year lists are described as complete in the sense that everything officially nominated is in, but the nomination rounds occasionally missed notable research, and the project invites issues or pull requests for anything that would qualify as a nominee for that year. Those later additions are visibly separated from the original nominations. They require a full private evaluation under the judging skill's current merit criteria, and they record Added or Not added decisions, with the decision history kept under the ai-evaluation directory, which holds candidate links and the history per year. A separate file for AI-collected candidates exists for a year with no vote yet, described as machine-assembled and unreviewed, and it is kept deliberately apart from the curated lists. The honest way to read the archive is therefore two layers: what was nominated, and what a later judgement added.

A research index, not a running tool

It is worth being clear about what this repository is and is not, since the name sounds like it could be a checklist. It contains no exploit code, no scanner and nothing that executes against a target. The primary language recorded for the project is Python, and the only Python in the tree is the capture driver that runs headless Chrome to take the PDF snapshots, plus the scripts that generate the site's catalogue and shards. The rest is Markdown, JSON, PDF and images. Its value is that it is a stable citation target: instead of linking to a blog post that will eventually 404, you can point at a year file that says what was nominated, and at a preserved copy of the original announcement. What it cannot do is replace the research itself, because it links to the papers and blog posts rather than reproducing them, and the terms of reuse for the archive are separate from the licences of the work being linked. The MIT licence field on the repository and the LICENSE file at the root cover the archive's own contents, and there is a reuse terms section in the README alongside a SECURITY file and a SUPPORT file, so the reuse question is answered in the repository rather than left to assumption.

Small, current, and waiting for the next year

The maintenance picture is simple. There are no GitHub releases, so there is no version to pin and no changelog of tagged versions. The last push was on 2026-10-16, and the tree shows a project that is still in motion: the root has a 2026-ai.md file for the coming year's candidates, and the .github, .agents, .claude and .codex directories alongside editor configuration, a CLAUDE.md and a CONTRIBUTING file. The archives are also split into a first-class and a secondary set, with an archived-references directory alongside the year files and the original-listings directory, which suggests the project keeps links that have moved out of the main collection rather than discarding them. The site is described as a progressive archive, meaning the collection grows as each year is announced, and the publishing registry exists so that automation can add a new year without anyone hand-editing the site data. For a reader, the practical habit is simple: read the year file, not just the winners section, and check the ai-evaluation directory when you want to know what the judgement did with the candidates the original rounds missed.

Editorial conclusion

webhacklist suits a security researcher, a teacher or a writer who wants the full nomination history of the Top 10 Web Hacking Techniques rather than the ten winners, and who wants it in a form that survives the next time an announcement post is taken down. It does not suit someone looking for a working exploit or a tool, because nothing here executes, and it does not replace the original research papers, which it links to rather than reproduces. Before using it, check the reuse terms in the repository, since the archive terms are not the same as the licences of the linked papers, and read the year file rather than only the winners section if you care about what was nominated.

Frequently asked questions

Official sources

1. irsdl/webhacklist on GitHub
2. Issues
3. License: MIT
4. Project website
5. README