xss

Cross-Site Scripting Detection

Overview

Cross-site scripting is an output-encoding failure: attacker-chosen data reaches a browser in a position where the browser parses it as markup or code, so script runs inside the victim's session for the vulnerable origin. Script running as the site can read and rewrite the DOM, steal cookies and tokens, read a page's anti-forgery token and issue fully valid state-changing requests, capture credentials with injected form fields, and act as the user. The attacker is a remote third party who either lures the victim to a crafted URL (reflected, DOM-based) or plants a payload the application later serves to other users (stored) — the latter reaches administrators and is the highest-impact form. This skill locates every site where untrusted data becomes part of a response or is handed to a client-side HTML/execution sink, checks each site in parallel, and merges the results into <output_dir>/xss-results.md.

What it is NOT

• Other client-side sink families (/websec:dom-based): test the sink, not the source. If the sink renders HTML or executes code (innerHTML, document.write, eval, Function, jQuery .html()), it belongs here — including DOM-based, reflected-DOM and stored-DOM cases. If the sink is navigation, document.cookie, localStorage, a request header, WebSocket(), JSON.parse, document.evaluate, executeSql, document.domain, or a plain DOM property, it belongs to /websec:dom-based. DOM clobbering and web-message origin flaws also live there; note here only when they are the delivery vehicle for a sink in this skill.
• Server-side template injection (/websec:ssti): if user input is concatenated into the template source and evaluated by the server's template engine, it is /websec:ssti (usually remote code execution). Client-side template expression evaluation in the browser stays here.
• Cross-site request forgery (/websec:csrf): CSRF makes the browser send a request it cannot read; XSS runs code and can read responses. XSS defeats anti-forgery tokens; the reverse is not true.
• Prototype pollution (/websec:prototype-pollution): polluting Object.prototype is the gadget, not the sink. Report it there and note the resulting HTML sink here only if untrusted data reaches it directly.
• Server-side injection (/websec:sql-injection, /websec:os-command-injection): different trust boundary — the database or the shell, not another user's browser.
• Upload handling (/websec:file-upload): an uploaded document that runs script in a viewer's browser is that skill's when the missing control is upload-side — type allow-list, stored extension, Content-Disposition, sniffing protection. Test: is the flaw that the file was accepted and served at all, or that its contents reach a rendering sink? Only the second is here.
• Open redirection (/websec:open-redirect, or /websec:dom-based when client JavaScript assigns the navigation): steering the browser to an attacker-chosen destination without achieving markup or script execution is not this class. Test: does the payload land in a parsed HTML or script context, or only in a destination the browser navigates to? A javascript: destination that genuinely executes is reported here and the redirect noted there.
• Content spoofing and embedding-based phishing: injecting text or styling that misleads a reader without reaching a markup or script context is a presentation and brand issue with no execution behind it. No skill in this set owns it. Test: name the parsed context the payload reaches; if there is none, it is out of scope — say so and move on rather than reaching for a neighbouring class.
• Not a finding: a reflection that is correctly encoded for the context it lands in; auto-escaping template output with no escape hatch on the path; self-inflicted payloads that require the victim to paste code into their own console or field with no cross-site delivery; a Markdown or rich-text pipeline whose maintained sanitiser output is the value actually rendered; developer-controlled constants that merely pass through an HTML sink.