songjianyang/xss-audit

This is worth a look if you already have an agent workflow and want a structured static XSS review checklist to run against a React/TypeScript/JavaScript codebase. It is a skill, not a scanner: installation means copying the skill file into your agent's skills directory, and the output is a Markdown report you still have to read and verify.

The problem

A developer or security reviewer wants to sweep a frontend codebase for XSS before release or during a bug-bounty pass. Typically they search for innerHTML, dangerouslySetInnerHTML, href, postMessage and similar sinks by hand, then trace each match back to a source and decide whether validation exists. That process is slow and easy to cut short. This skill changes the step after the search: it gives the reviewing agent 14 layers of check prompts and a report format with source, sink, data flow and a fix suggestion, so the human gets a structured list to verify instead of raw grep hits. The result is a review document, not a confirmed vulnerability list.

What's different

The breadth of the checklist is the main draw. It goes past DOM sinks into attributes and event handlers, URL and navigation validation, SSR bootstrap and JSON-LD script breakout, prop spreading, postMessage origin checks, prototype-pollution chains, eval/Function/Blob execution, CSS injection, SVG/MathML namespaces, markdown and sanitizer/mXSS handling, framework trust hooks such as Vue v-html and Lit unsafeHTML, Trusted Types/CSP, and framework binding/template-injection paths. The README frames this as distilled from the author's bug-bounty work and cites four consecutive quarterly Top-10 placements on Microsoft's MSRC researcher leaderboard for 2025 Q3 through 2026 Q2 (leaderboard, profile). That is a credibility signal about the author's process, not independent evidence that the skill finds every issue.

The output design is where the trade-off shows. Each finding must document location, source/sink/data flow, vulnerable code, a fix, confidence and verification status, and reproduction notes that separate theoretical steps from executed ones. There is a separate manual-review section for incomplete data flows, and a per-layer search summary that distinguishes pattern matches from confirmed vulnerabilities (sample report). That structure is useful for triage, but it also means the tool is honest about doing only static analysis. The README explicitly says a search match is not a confirmed vulnerability, and warns about false positives and false negatives from runtime behavior, build-time transforms, excluded code and framework timing. You should budget time for the verification pass; the report is a starting point for human review.

Who should try it

Good fit: a frontend or application-security engineer who already uses a coding agent with a skills mechanism, wants a repeatable XSS checklist for React/TypeScript/JavaScript repos, and is willing to verify findings manually. It is also a reasonable fit for a bug-bounty hunter who wants to compare their own review process against a broader set of sinks.

Poor fit: anyone expecting a CI scanner that blocks merges or produces a definitive vulnerability count. The README gives no automated test harness, no dependency install and no runtime checks, and it explicitly says no coverage is guaranteed. If your codebase is mostly server-rendered in another language, or you need dynamic proof-of-concept execution, this skill's layer list is not aimed at that.

Requirements and limitations

The setup is minimal: copy xss-audit/SKILL.md into your agent's skills directory and invoke /xss-audit or /xss-audit src/ (project README, SKILL.md). There is no package manager step or service to run, but you do need an agent that supports skill files; without that, the checklist is just reading material.

The larger constraint is the static-only scope. Findings need manual confirmation, and the report may include sensitive paths, source code, internal domains or credentials, so it should be reviewed and sanitized before sharing. The license is MIT (license), so adapting the checklist to your own review process is straightforward. The README does not document per-project configuration beyond the target path argument, so expect to adapt the layer descriptions to your framework mix.

HotRepo's take

HotRepo first tracked this repository on 2026-10-24, and by 2026-10-25 it had 339 total stars and ranked #20 on the NEW-REPOSITORY board (新项目榜, all languages) (repository). That is one dated snapshot, not a growth series; persistence cannot be judged from it. As an adoption decision, the useful next check is whether the 14 layers map onto your actual stack, especially if you rely on a framework not covered in the trust-hook list, before you invest in running it.