Cross-Site Scripting (XSS)
A security vulnerability where an attacker injects malicious scripts into a trusted website.
Detailed Explanation
XSS occurs when an application includes untrusted data in a web page without proper validation or escaping. The malicious script runs in the victim's browser, potentially stealing session cookies, redirecting users, or defacing the site. Defenses include using a Content Security Policy (CSP), sanitizing user input, and using modern frameworks that escape data by default.
Quick Summary
XSS lets an attacker run their JavaScript in a victim's browser by tricking the site into rendering attacker-controlled content as code instead of text. It's the most prevalent web vulnerability and the gateway to session hijacking and account takeover.
Key Takeaways
- Three flavors: stored (payload saved in DB), reflected (echoed from a URL/form), DOM-based (client-side JS sinks dangerous data into innerHTML or eval).
- Defense in depth: escape on output, validate on input, set a strict Content Security Policy, use HttpOnly + SameSite cookies.
- Modern frameworks (React, Vue, Svelte) escape interpolated text by default, XSS in them usually requires dangerouslySetInnerHTML or v-html.
- Cookies marked HttpOnly are invisible to JS, blunting the impact of XSS for session theft.
- `innerHTML`, `document.write`, and `eval` are the classic sinks; treat any user data flowing into them as suspect.
When to use it
- Audit checklists during code review, search for innerHTML and dangerouslySetInnerHTML.
- Security training: XSS is the canonical example used to teach output escaping and CSP.
- Penetration test scope items for any user-content-rendering app.
- Bug bounty submissions, XSS pays well because it's almost always exploitable.
Common Mistakes
- Sanitizing on input only, then trusting the data at output. Always escape at the boundary where context is known (HTML, attribute, JS, URL).
- Using a sanitizer not designed for HTML (regex replace, escape), only library-grade tools like DOMPurify handle the edge cases.
- Rendering user-submitted markdown as raw HTML without sanitization.
- Believing a CSP alone fixes XSS, CSP mitigates impact but isn't a substitute for output encoding.
Cross-Site Scripting (XSS), Frequently Asked
Does using React protect me from XSS?
Mostly. React escapes interpolated content by default. The exceptions are `dangerouslySetInnerHTML`, javascript: URLs, and direct DOM manipulation. Audit those, and you've eliminated most of the surface.
What's the difference between stored and reflected XSS?
Stored XSS lives in the database, every visitor to the affected page runs the payload. Reflected XSS requires the victim to click a crafted URL that echoes attacker input back into the page. Stored is more dangerous; reflected requires social engineering.
Is CSP a replacement for output escaping?
No. CSP is a strong mitigation layer that limits what injected scripts can do, but a well-tuned CSP still requires that you escape output correctly. They are complementary, not substitutes.