Cross-site scripting (XSS): script that runs as your site

Definitions follow OWASP and CWE-79.

A page includes something a user supplied: a search term, a name, a comment. If the page inserts it as markup instead of as text, an attacker can supply markup that contains a script. Every browser that loads the page runs the script with the site's identity.

From there the script can do whatever the page can: read data shown to the user, send requests with their session, change the page to ask for a password. The site's own trust becomes the attacker's tool, which is why XSS on a trusted site is serious even when it looks small.

• Reflected XSS. The script travels in the request, usually a link, and the page reflects it straight back. The victim has to open a crafted link.
• Stored XSS. The script is saved, for example in a comment or profile, and served to everyone who views it. No crafted link is needed.
• DOM-based XSS. The page's own JavaScript takes data from the URL or another source and writes it into the page unsafely, so the server may never see the script.

The difference decides who can see the attack. Reflected and stored XSS pass through the server; DOM-based XSS can live entirely in the browser.

Both use the victim's browser, but in opposite directions. XSS runs attacker script inside your site, so it can read and do anything the page can. CSRF makes the victim's browser send a request to your site from somewhere else; it can make requests but cannot read the responses.

An XSS flaw also defeats most CSRF protection, because script running on the site can read the anti-forgery token like the page does.

A request filter matches script tags, event handlers and other markup in parameters, and refuses or records them. That covers many reflected and stored attempts, because the script has to arrive in a request at some point.

It misses DOM-based XSS that never reaches the server, payloads encoded or split in ways the rules do not decode, and stored script that arrived through a channel the filter does not read. Fields where users legitimately write markup produce false positives.

1. Encode output for its context. HTML body, attribute, JavaScript and URL contexts each need their own encoding; the OWASP XSS Prevention Cheat Sheet lists the rules.
2. Use a framework that encodes by default. And treat every place that bypasses it as a review point.
3. Avoid writing untrusted data into the page with script. Use APIs that set text, not markup.
4. Add a Content Security Policy. A CSP limits which scripts the browser will run, so an injected script is refused even if it gets into the page; see Content Security Policy.
5. Mark session cookies HttpOnly. Script cannot read them, which limits what a successful XSS can steal; see session hijacking.