XSS (Cross-Site Scripting) is a vulnerability where an attacker gets their JavaScript to run inside your site’s origin. Once it runs, it has full access to cookies, localStorage, the DOM, and any authenticated user’s data.
Types of XSS
- Reflected — user input reflected into a page:
?q=<script>...</script> - Stored — attacker content saved to your DB and rendered later (comments, user profiles)
- DOM-based — client-side code reads from a URL or storage and writes it unsafely
What attackers do with it
- Read session cookies (if not
HttpOnly) - Read
localStoragetokens - Make authenticated API requests as the user
- Capture keystrokes on login forms
- Deface or phish
Defenses
- Escape all output. Every templating framework escapes by default — don’t disable it.
- Content-Security-Policy (CSP). Strict CSP (
script-src 'self') turns most XSS into an error instead of a compromise. - HttpOnly session cookies. Prevents XSS from stealing them.
- Sanitize rich-text input server-side. DOMPurify on the client isn’t enough.
- No
eval, noinnerHTMLwith user input, nodangerouslySetInnerHTMLwithout sanitization.
XSS vs CSRF
XSS runs code in your origin. CSRF rides the user’s browser’s authority. Different threats, different defenses.
See the full auth glossary for related terms.