Cross-Site Scripting (XSS) Deep Dive: Stored, Reflected, and DOM-Based
How malicious JavaScript executes in victim browsers, steals session tokens, and how to defend with Content Security Policy.
1. What Makes Client-Side Script Execution Dangerous
While SQL Injection targets the backend server and its storage, Cross-Site Scripting (XSS) turns the vulnerable web application into an attack platform directed against its own legitimate users.
Browsers enforce the Same-Origin Policy (SOP) to isolate scripts from different domains. However, if an attacker successfully injects JavaScript into your website's origin, the browser executes it with all the authority and trust of your legitimate domain.
2. The Three Flavors of XSS
Stored (Persistent) XSS: The malicious script is permanently stored on the target server (e.g., in a comment field, user profile biography, or forum post). Whenever any user visits that page, the script executes automatically.
Reflected XSS: The script is reflected off the web server in an immediate error message, search result, or URL parameter. The attacker must trick the victim into clicking a crafted phishing link containing the payload.
DOM-Based XSS: The vulnerability exists entirely on the client side. JavaScript code dynamically takes input from an untrusted source (like location.hash) and writes it into an unsafe DOM sink (like innerHTML or eval()) without sending it to the server.
// VULNERABLE DOM-XSS pattern:
const search = new URLSearchParams(window.location.search).get('q');
document.getElementById('results').innerHTML = 'You searched for: ' + search;
// SECURE: Use textContent to treat data strictly as plain text
document.getElementById('results').textContent = 'You searched for: ' + search;3. Cookie Protection: HttpOnly and SameSite
The most common goal of an XSS payload is stealing the victim's session cookie via 'document.cookie' and sending it to an external server.
Developers must configure all authentication cookies with the 'HttpOnly' flag. This instructs the browser that the cookie cannot be read by JavaScript under any circumstances, drastically reducing the impact of XSS on session hijacking.
4. Content Security Policy (CSP)
Content Security Policy is an HTTP response header that allows site operators to restrict which resources (scripts, images, stylesheets) the browser is allowed to load and execute.
A strong CSP prevents inline scripts ('unsafe-inline') and requires scripts to carry a cryptographic nonce or SHA-256 hash, stopping injected script tags from running even if an injection flaw exists in HTML.
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m123'; object-src 'none'; base-uri 'self';