Cross-site scripting

XSS is commonly classified into three main types based on how the malicious script is delivered. Reflected XSS occurs when the injected script is part of a request (e.g., a URL parameter) and is immediately reflected in the response without sanitization; the victim must click a crafted link. Stored XSS persists on the server (e.g., in a database) and executes whenever any user views the affected page, making it more severe. DOM-based XSS arises entirely in client-side JavaScript, where untrusted data modifies the Document Object Model (DOM) without ever being sent to the server. Each type exploits the trust a browser places in a legitimate origin, often bypassing security measures like Content Security Policy if misconfigured.

The consequences of XSS range from data theft to full account takeover. Attackers can steal cookies, session tokens, or credentials, impersonate users, and perform actions on their behalf. In 2005, the Samy worm exploited a stored XSS vulnerability in MySpace, spreading to over one million users within hours.³ More recently, XSS has been used to deliver ransomware, deface government sites, and mine cryptocurrencies in visitors' browsers. The 2020 Twitter Bitcoin scam, though not purely XSS, highlighted how social engineering combined with script injection can cause widespread financial damage. Even low-severity XSS can be chained with other vulnerabilities, such as CSRF, to escalate privileges.

Defense against XSS requires a multi-layered approach. The primary countermeasure is output encoding—escaping user-controlled data according to the context (HTML, attribute, JavaScript, CSS, or URL) before rendering.⁴ Input validation, using allowlists for expected formats, reduces attack surface. Content Security Policy (CSP) acts as a secondary defense, restricting script sources and blocking inline scripts. Modern frameworks like React and Angular auto-escape by default, but developers must still avoid dangerous APIs like innerHTML. Regular security testing, including automated scanners and manual penetration testing, helps identify gaps. The OWASP Cheat Sheet Series provides detailed guidance on each mitigation technique.

Beyond the basics, XSS has subtle and surprising dimensions. Mutation XSS (mXSS) exploits browser parser quirks to bypass sanitizers, as demonstrated in 2013 by researchers who found that HTML5 parsing could mutate supposedly safe markup into executable scripts. Universal XSS (UXSS) occurs when a browser vulnerability allows script injection across all origins, often via flawed extension APIs. XSS has also been used as a vector for client-side denial of service, where scripts consume excessive resources. In 2019, a stored XSS in the popular MathJax library was used to steal credentials from academic sites. Additionally, XSS can be leveraged for port scanning and keylogging without the victim's knowledge, turning a simple injection into a full surveillance tool.

Same-origin policy

A browser security mechanism that restricts scripts from accessing data from a different origin (scheme, host, or port).

Reflected XSS

A type of XSS where the injected script is reflected off a web server in the immediate response, often via a crafted URL.

Stored XSS

A type of XSS where the malicious script is permanently stored on the target server and executed when other users view the page.

DOM-based XSS

A type of XSS that occurs entirely in client-side JavaScript, where untrusted data modifies the Document Object Model without server interaction.

Content Security Policy (CSP)

A browser security standard that allows web administrators to restrict which resources (e.g., scripts) a page can load, mitigating XSS.

Mutation XSS

A sophisticated XSS variant that exploits browser parsing quirks to bypass sanitization, turning harmless markup into executable scripts.