Glossary
What is XSS (Cross-Site Scripting) — code running in someone else's browser
XSS (Cross-Site Scripting) makes an attacker's script run in another user's browser, leading to session theft and page tampering. The three types (stored/reflected/DOM), how it works, and the real defense (output escaping, framework auto-escaping, CSP) — explained defensively, without attack steps.
"The text I typed into a form runs as a script on someone else's screen" — that's XSS. Here's how it works and how to reliably prevent it (no attack steps).
The three types
XSS splits by "how the malicious string reaches execution."
| Type | How it's planted |
|---|---|
| Stored | Saved in a post/profile and runs for everyone who views it (most dangerous) |
| Reflected | A URL parameter is reflected straight back into the page; runs for whoever clicks the link |
| DOM-based | No server round-trip — client-side JS handles input unsafely |
Why it's dangerous (how it works)
The browser runs any <script> in the page as "legitimate code." If an attacker's string lands as HTML in the page, the browser can't tell it from real code.
The damage is "everything that page can do." If RCE is the worst on the server side, XSS is the worst on the client (user) side.
Defense: the real fix is "escape on output"
XSS is prevented at output, not input. The moment you render a value, convert it so it can't be interpreted as HTML.
Escape on output (most important)
When rendering user-supplied values, convert < > & " ' to HTML entities — using the right method for the context (HTML body, attribute, JS, URL).
Don't disable your framework's auto-escaping
React/Vue/templates auto-escape by default. Just avoid raw-HTML injection (dangerouslySetInnerHTML, v-html) and you prevent most XSS.
Defense in depth with CSP
Content-Security-Policy lets the browser block scripts you didn't allow, limiting damage even if something slips through.
Protect cookies
Mark session cookies HttpOnly so JS can't read them. Even if stolen, the blast radius is smaller.
ITD's view: the best defense is not opening the hole yourself
Modern frameworks default to safe. Most XSS appears the moment a developer deliberately disables auto-escaping to "inject raw HTML." If you truly must allow HTML, run it through a battle-tested sanitizer, not your own string handling. "Disabling safety for convenience" is the biggest risk.
Read next
- Glossary: What is CSRF · What is RCE
- Basics: Security basics
FAQ
QWhat happens with XSS?
An attacker's script runs in the victim's browser as part of the real page. That can mean session theft (impersonated login), reading input, defacing the page, or auto-running other actions.
QWhat's the top defense against XSS?
Escaping on output: when you render user-supplied values, convert them so they aren't interpreted as HTML. React/Vue templates do this by default, so the biggest win is to not disable that auto-escaping (avoid dangerouslySetInnerHTML, etc.). Add CSP for defense in depth.
QIs sanitizing on input enough?
Usually not. The real fix is escaping per output context (HTML body, attribute, JS, URL). Input filters alone leak via context mismatches. Only when you must allow HTML, run it through a trusted sanitizer.