Safety

XSS

2000ActivePublished: 29 September 2026Updated: 29 September 2026Published

Key innovation

Established that a browser's trust in content served by a site can be abused by injecting executable script through unvalidated or unencoded input, and made context-aware output encoding the primary defense.

How it works

1) The attacker identifies an entry point where user-controlled data (URL parameter, form field, header, database content) is placed into a response without neutralization. 2) They craft a payload containing script markup or code (e.g., <script>, an onerror event attribute, a javascript: URI). 3) The payload is delivered: in Reflected XSS via a crafted link or request whose script is immediately reflected in the response; in Stored XSS by persisting the payload on the server (comment, forum post, log) so it is served to subsequent visitors; in DOM-based XSS via client-side JavaScript that writes untrusted data into a dangerous sink (e.g., innerHTML) without the data ever leaving the browser. 4) The victim's browser executes the script in the trusted site's origin, gaining access to cookies, session tokens, and the DOM, enabling session hijacking, data theft, keylogging, or further requests on the victim's behalf.

Problem solved

Names and organizes the class of vulnerabilities in which untrusted input reaches an executable browser context (HTML, attributes, JavaScript, CSS, URL) without proper encoding or sanitization. Understanding XSS enables defenses—context-aware output encoding, HTML sanitization, and Content Security Policy—that keep data as data rather than code.

Components

Reflected XSS (Type-I)Non-persistent variant

The injected script is immediately reflected off the server in a response (e.g., an error message or search result) and executes when the victim opens a crafted link or request. Also called non-persistent or Type-I XSS.

Stored XSS (Type-II)Persistent variant

The malicious script is permanently stored on the target server (database, forum, visitor log, comment field) and served to subsequent users. Also called persistent or Type-II XSS. Blind XSS is a stored form whose payload executes later, when a back-end administrator views the content.

DOM-based XSSClient-side variant

A client-side vulnerability, identified in 2005, occurring when JavaScript manipulates the DOM using untrusted data, writing it into a dangerous sink (e.g., innerHTML, document.write, eval) without server involvement.

Implementation

Reference implementations

DOMPurify

JavaScript · Cure53 (HTML sanitization library — XSS defense)

OWASP Java Encoder

Java · OWASP (context-aware output encoding)

Implementation pitfalls

Writing untrusted data to dangerous sinksCritical

Using innerHTML, document.write, eval, or framework escape hatches (React dangerouslySetInnerHTML, Angular bypassSecurityTrustAs*, Lit unsafeHTML) to insert user-controlled data bypasses built-in protections and leads to DOM-based XSS.

Fix:Prefer safe sinks that treat input as text: .textContent, .setAttribute(), .value, .insertAdjacentText(). For user-authored HTML, use a sanitizer (e.g., DOMPurify) and keep it patched.

Missing context-aware output encodingHigh

Placing data without encoding appropriate to its context (HTML, attribute, JavaScript, CSS, URL) allows breaking out of the data context. HTML encoding does not protect inside <script>, HTML comments, <style> blocks, or event-handler attributes.

Fix:Apply context-aware encoding: HTML entity encoding in HTML content, attribute encoding, \uXXXX in JavaScript values, \XX in CSS, percent-encoding in URLs. Never place variables directly into executable contexts.

Relying on blacklist input filteringHigh

Attempting to block XSS with blacklists of words/characters is easy to bypass (encoding, alternative vectors, new HTML elements) and creates a false sense of security.

Fix:Treat input validation as a secondary defense (allowlist), not the primary one. The foundation is output encoding and HTML sanitization at the point of use.

Treating CSP as the sole protectionMedium

Content Security Policy is sometimes mistaken for a primary defense; misconfigured or overly permissive policies (e.g., unsafe-inline) will not stop XSS, and uniform enterprise-wide policies can break legacy systems.

Fix:Use CSP as defense-in-depth (nonces/hashes, no unsafe-inline), tailored per application, not as a replacement for output encoding and sanitization.

Evolution

Original paper · 2000 · CERT Coordination Center (CERT/CC)

CERT Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests

2000

Term coined and first CERT advisory

Inflection point

Microsoft security engineers coined the term 'cross-site scripting'; CERT/CC published advisory CA-2000-02 describing injection of malicious HTML tags in web requests.

2005

DOM-based XSS defined

Inflection point

DOM-based XSS was described as a distinct client-side variant in which the payload never leaves the browser.

2013

XSS as A3 in OWASP Top 10

In the OWASP Top 10 (2013), Cross-Site Scripting was ranked as its own risk category, A3.

2021

XSS folded into Injection category

In the OWASP Top 10 (2021), Cross-Site Scripting was folded into the broader A03:2021 – Injection category.