XSS

In 2005, Samy Kamkar wrote a self-propagating XSS worm on MySpace. The worm added him as a friend on every visitor's profile. Within 20 hours, over one million users had been affected. MySpace had to shut down the entire site to remove it. The worm worked because MySpace did not sanitize profile content, so JavaScript in one user's profile executed in every other user's browser.

XSS is not a relic. In 2018, British Airways had a Magecart attack where injected JavaScript on the payment page skimmed 380,000 credit card numbers over two weeks. In 2019, a Fortnite XSS vulnerability in the account login flow could steal user sessions and make in-game purchases. In 2023, Cloudflare reported blocking 2.5 billion XSS attempts per month across their network.

The core problem: your web page renders content that a user (or attacker) provided, and the browser cannot tell the difference between your legitimate JavaScript and injected malicious code. If the attacker can get their script to execute in another user's browser, they own that user's session. They can read anything on the page, modify the DOM, steal cookies (unless HttpOnly is set), and send data to their own server.

Modern frameworks like React, Vue, and Angular auto-escape content by default, which prevents most XSS. But developers create bypasses with dangerouslySetInnerHTML, v-html, href={userInput} (javascript: URLs), and server-side rendering that interpolates user input into HTML strings. Each bypass is a potential XSS vector.

XSS comes in three variants, each with a different attack surface, persistence model, and detection difficulty. Understanding which type you are defending against determines which controls matter most.

Stored XSS is the most dangerous. The attacker submits a script through any input that gets saved to the database: comments, profile fields, forum posts, product descriptions. Every future visitor loads and executes the script. The attacker can harvest thousands of session cookies overnight without being online. The British Airways breach was stored XSS injected into a third-party script on the payment page.

Reflected XSS is the most common. The payload is in a URL parameter that the server echoes back without encoding. The attacker sends the crafted URL to victims via email, chat, or embedded in another site. Each victim must click the link. Search pages are the classic example: /search?q=<script>alert(1)</script> where the server renders "Results for: <script>alert(1)</script>" without encoding.

DOM-based XSS is invisible to the server. Client-side JavaScript reads from a tainted source (location.hash, document.referrer, postMessage) and writes to a dangerous sink (innerHTML, eval, document.write). The payload never touches the server, so server-side sanitization and WAFs cannot detect it. SPAs are particularly vulnerable because they manipulate the DOM heavily based on URL fragments and client state.