PortSwigger/xss-cheatsheet-data is the community-driven JSON dataset behind PortSwigger's official cross-site scripting cheat sheet, maintained for authorized web security testing and defensive research.
| Tool | PortSwigger/xss-cheatsheet-data — the JSON dataset powering PortSwigger's official XSS cheat sheet, open for community pull requests |
| Category | Web application security reference data |
| Primary Use | Consulting event-handler vectors, supported tags, browser compatibility, and interaction requirements during authorized XSS testing and filter research |
| Safe Use | For authorized penetration tests, lab environments such as PortSwigger Web Security Academy, and defensive research into payload taxonomies and WAF filter design |
| Telemetry Note | This is a static reference dataset with no runtime footprint; defenders benefit from it as a corpus of known event-handler vectors useful for building detection and filtering signatures |
Most security professionals have bookmarked the PortSwigger XSS cheat sheet at some point in their careers; what PortSwigger/xss-cheatsheet-data does is expose the machinery behind it. The repository is the canonical JSON dataset that powers the cheat sheet hosted at portswigger.net, and its existence on GitHub is a deliberate editorial decision: rather than maintaining the reference internally, PortSwigger opened the data so that community members can contribute new vectors via pull requests. With 471 stars and a master default branch, it has become a quiet piece of shared infrastructure for the web security community, sitting somewhere between documentation project and collaborative database.
Structurally, the repository is pure data. There is no runtime tool, no scanner, no exploit framework — just structured JSON describing cross-site scripting vectors in a machine-readable form. Each top-level key is an event handler name, such as onwaiting, and its value contains a description field explaining when the event fires plus a tags array. That array is where the operational detail lives: each entry specifies the tag the vector applies to, a code field containing the example markup, a browsers list, and an interaction boolean. The schema is simple enough to parse with a few lines of any scripting language, which is precisely the point — the same data that renders as a human-readable cheat sheet can drive tooling.
The README walks contributors through the workflow with a worked example for onwaiting, an event that fires on a video element while media playback is stalled waiting for data. The example vector wraps the handler in a video element with autoplay and controls attributes and a valid source child pointing at an mp4 file, and it is annotated as working only in edge. That example is instructive beyond its content: it shows the level of specificity expected from contributions. Browser support is not guessed at, interaction requirements are not assumed, and the description explains the semantics of the event rather than just naming it.
The supported browser vocabulary is deliberately constrained. The README specifies that browser identifiers must be chrome, safari, firefox, or edge, all lowercase. This normalization matters for anyone consuming the data programmatically, because it means filters and lookups can key off a fixed enum rather than fuzzy-matching vendor strings. For an authorized assessment, this translates directly into workflow value: if you are validating an input reflection in a target you own or are contracted to test, you can filter the dataset to vectors known to execute in the specific browser relevant to your engagement, rather than spraying markup blindly.
The interaction flag deserves particular attention from both testers and defenders. It records whether a vector requires user interaction before the event fires — a meaningful distinction between vectors that trigger automatically during page load and those that need a victim to click, hover, or otherwise engage with the page. From a defensive research perspective, this metadata is useful for threat modeling: vectors with interaction: false represent the higher-risk class for reflected injection scenarios, while interaction-dependent vectors factor into assessments of phishing-assisted attack chains. Few public payload corpora carry this annotation, and it is one of the dataset's distinguishing strengths.
Contribution hygiene is covered in the README as well. Contributors are asked to search the existing data before submitting to avoid duplicate vectors, and to include their Twitter handle in the pull request message if they want credit. The change format is a pull request against the JSON files, which means every vector in the corpus carries a visible review trail in the repository's commit history. For researchers studying how payload knowledge evolves across browser releases, that history is itself a dataset — you can trace when a vector was added, by whom, and in response to which browser behavior.
The licensing situation is unusual and worth flagging before anyone builds on this. The README states that copyright belongs to PortSwigger Web Security and that no license is provided, explicitly because PortSwigger does not want the data used to create derivative cheat sheets hosted elsewhere. Forking is permitted, but specifically in service of creating pull requests back upstream. This is a genuine constraint: ingesting the dataset into a commercial product, a mirrored reference site, or a repackaged cheat sheet would go beyond what the maintainers authorize. Reading it, scripting against a local clone for internal test tooling, and contributing back are the clearly sanctioned uses.
Where this fits in an authorized workflow is straightforward. During a scoped penetration test, once you have confirmed an injection point, the dataset serves as a compact lookup for which event handlers are viable on which tags in which browsers, cutting down the trial-and-error loop. In PortSwigger's own Web Security Academy labs it maps directly to the exercise material, since the labs and the cheat sheet share a common conceptual ancestry. And for anyone studying for web security certifications built around the Academy curriculum, the JSON structure is arguably a better study aid than the rendered cheat sheet, because the schema forces you to think about why a vector works, not just that it does.
For the defensive side, the value is in signature and filter engineering. The corpus enumerates a wide range of on* event handlers paired with the HTML tags that support them, which is exactly the shape of knowledge needed to build or tune output-encoding routines, sanitizers, and WAF rules. A defender reviewing which vectors require no interaction can prioritize which event-handler patterns their encoding library must neutralize unconditionally. The browser metadata also helps with risk acceptance decisions — a vector that only fires in edge may warrant different treatment in a heterogeneous enterprise estate than one that works across all four supported browsers.
There are honest limitations to note. The repository is data, not tooling, so anyone wanting to consume it programmatically will write their own access layer — the schema is simple enough that this is a minor task, but it is real work. The browser list caps at four vendors, leaving mobile browsers and less common engines outside the corpus. And because contributions arrive via community pull requests, coverage reflects what contributors have tested rather than a systematic sweep, so absence of a vector from the data is weaker evidence than its presence. Treat it as a strong positive reference, not an exhaustive enumeration.
What makes xss-cheatsheet-data interesting as a project is the model it represents. PortSwigger took a high-traffic reference asset, decoupled its presentation from its content, and opened the content to the same community that uses it, while fencing off commercial derivation through license language. The result is a living document with a reviewable history, a strict schema, and a clear contribution path — a pattern other security reference projects could adopt. For professionals, it is worth a clone and a skim of the JSON structure if only to understand the taxonomy of event-based vectors; for anyone building internal test utilities or defensive filters, it is one of the cleanest annotated payload corpora available, provided you respect the terms under which it is published.
PortSwigger/xss-cheatsheet-data.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.