Cross-Site Scripting (XSS).

Cross-Site Scripting (XSS) occurs when a web application reflects or stores untrusted input in its responses without context-aware escaping, letting attacker-controlled JavaScript run in the victim's browser under the site's origin — inheriting its cookies, DOM access, and same-origin privileges. The three classes are reflected (payload echoed from the request), stored (payload persisted server-side, e.g. in a comment), and DOM-based (the sink lives in client-side JavaScript such as innerHTML or document.write).

The canonical demonstration of stored XSS's reach is the Samy worm: on 4 October 2005 Samy Kamkar planted a JavaScript payload on his MySpace profile that added him as a friend and copied itself to each viewer's profile. It infected over one million accounts in under 20 hours — the fastest-spreading worm at the time — and led to a Secret Service raid and a felony plea. XSS remains a staple of the OWASP Top 10, folded into A03:2021 (Injection).

Defences are layered: context-aware output encoding (HTML, attribute, JS, URL), a strict Content-Security-Policy with nonces or hashes to block inline script, framework auto-escaping (React, Angular), Trusted Types to lock down dangerous DOM sinks, and HttpOnly/SameSite cookies to limit session theft. Input validation helps but is not sufficient on its own.

flowchart LR
  A[Attacker submits payload] --> W[Web app stores or reflects input]
  W -->|Unescaped output| V[Victim browser renders page]
  V --> X[Attacker script runs in site origin]
  X --> S[Steal cookies/session, keylog, pivot]