XSS — Stored vs Reflected vs DOM-Based
Fast recall
Quick revision
Core answer
th:utext) for server-rendered views.Whether the candidate can distinguish XSS variants and knows server-side vs client-side prevention strategies.
Thinking that escaping HTML on input is sufficient — output context matters (HTML, JS, URL, CSS contexts need different encoding).
Mention Spring's Thymeleaf auto-escaping, the role of Content-Security-Policy, and how HttpOnly cookies mitigate session hijacking via XSS.
Interview-ready guide
Interview answer
XSS — three types
Stored XSS
- Attacker posts
in a comment - Stored in DB
- Every viewer runs the script
Reflected XSS
- Attacker crafts URL with script in a parameter
- Server reflects it back unescaped
- Victim clicks the link
DOM XSS
- JS reads untrusted data (URL hash, localStorage) and writes to DOM via
innerHTML - No server round-trip
Prevention
Output encoding
- Escape HTML entities —
<->< - Thymeleaf
th:textdoes this automatically
Content Security Policy
default-src 'self'; script-src 'self'- Most powerful defense — blocks even successful injections
- Use nonce-based CSP if you need inline scripts
HttpOnly cookies
- JS can't access them — session safe even with XSS
- Spring Security default for session cookies
Spring Boot specifics
http.headers()enables CSP, HSTS, X-Frame-Options- Thymeleaf is safe by default — never use
th:utextwith user content - For SPAs: client-side framework escaping + CSP at the API
Output context rule
- HTML body -> HTML entities
- JS string -> JS escaping (
\u00xx) - URL attribute -> URL encoding
- CSS context -> CSS escaping
- Mixing them up leaves vulns open
XSS — Stored vs Reflected vs DOM-Based
Direct Answer
XSS injects malicious JavaScript into pages viewed by other users — running with the same trust as legitimate scripts (read cookies, call APIs, exfiltrate data). Stored XSS persists in the DB and executes for every visitor. Reflected XSS is delivered via a crafted URL and executes immediately. DOM-based XSS is purely client-side — the server never sees the payload. Defense is output-context-aware encoding, not input filtering: HTML entity encoding for HTML body, JS escaping for script context, plus Content Security Policy as the last line, HttpOnly cookies to block session theft, and Thymeleaf th:text (never th:utext) for server-rendered views.
Common Mistakes & Pitfalls
Thinking that escaping HTML on input is sufficient — output context matters (HTML, JS, URL, CSS contexts need different encoding).
Check your understanding
Answer these without looking back at the article.
- How does a Content Security Policy header prevent XSS, and what is a nonce-based CSP?
- If you allow users to submit rich text (bold, links), how would you safely render it?
- What is the difference between XSS and CSRF — can an attacker exploit both simultaneously?
- How do you defend against DOM-based XSS in a single-page application?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.