Cross-Site Scripting (XSS)

What is cross-site scripting?

Cross-site scripting (XSS) is an attack where an attacker injects malicious JavaScript into a web page that other users then view, causing that script to run in the victims’ browsers with the victims’ privileges for that site. The root cause mirrors SQL injection: the application takes untrusted input and puts it into a web page without properly encoding it, so the browser interprets attacker-supplied text as executable script rather than inert content. Because the script runs in the victim’s authenticated session, it can steal session cookies, hijack accounts, capture keystrokes, deface pages, or make requests as the user.

The three types, and what they enable

XSS comes in three flavors worth distinguishing. Stored (persistent) XSS — the malicious script is saved on the server (in a comment, profile field, message) and served to everyone who views that content; the most dangerous because it hits many victims automatically. Reflected XSS — the script rides in a crafted URL or request and is immediately reflected back in the response, so the attacker must lure each victim into clicking a malicious link. DOM-based XSS — the vulnerability lives entirely in client-side JavaScript that unsafely handles input and writes it into the page (e.g., via innerHTML), never touching the server. What any of them enables is serious: since the injected code runs with the victim’s session, it can perform session hijacking (stealing cookies or tokens), act as the user, exfiltrate data on the page, or pivot to further attacks. XSS is a perennial OWASP Top 10 entry.

Prevention: encode on output, and add CSP

The primary defense is context-aware output encoding (escaping): whenever user-controlled data is inserted into a page, encode it for the context it lands in (HTML body, attribute, JavaScript, URL) so it’s rendered as text, not executed as code — <script> becomes harmless displayed characters. Modern frameworks (React, Angular, Vue) auto-escape by default, which is why they prevent most XSS — the danger returns when developers deliberately bypass that (dangerouslySetInnerHTML, v-html, innerHTML) with untrusted data. Layered defenses matter: a Content Security Policy (CSP) restricts what scripts a page may run, sharply limiting XSS impact even if injection occurs; input validation reduces the attack surface; and setting cookies HttpOnly stops injected JavaScript from reading session cookies. The mistake is treating input filtering alone as sufficient — the reliable fix is correct output encoding for the right context, backed by CSP.

What people get wrong

• Blocklist input filtering as the main defense — attackers bypass filters; the reliable fix is context-aware output encoding plus CSP.
• Bypassing framework auto-escaping: dangerouslySetInnerHTML / innerHTML with untrusted data reintroduces XSS the framework was preventing.
• Forgetting HttpOnly cookies and CSP — without them, a single XSS can steal sessions and run arbitrary scripts unchecked.

Primary source: OWASP: Cross Site Scripting (XSS)