What is XSS?
Learn what XSS (Cross-Site Scripting) is, its stored, reflected, and DOM-based types, and how escaping and CSP prevent it.
Expected Interview Answer
XSS (Cross-Site Scripting) is a vulnerability where an attacker injects malicious JavaScript into a page viewed by other users, letting that script run with the victim's browser session and steal cookies, log keystrokes, or perform actions as the victim.
XSS happens when an application takes untrusted input — a comment, a URL parameter, a profile field — and renders it into the page without properly escaping or sanitizing it, so the browser treats injected text as executable script rather than plain content. There are three main types: stored XSS, where the malicious script is saved on the server and served to every visitor; reflected XSS, where the script comes from a crafted URL and is echoed back in the response; and DOM-based XSS, where client-side JavaScript itself inserts untrusted data into the DOM unsafely. Because the injected script runs in the victim's browser as if it belonged to the trusted site, it has full access to that page's cookies, local storage, and ability to make authenticated requests. Defenses include escaping output by context (HTML, attribute, JS, URL), using frameworks that auto-escape by default, setting a Content-Security-Policy header, and marking sensitive cookies HttpOnly so scripts cannot read them.
- Understanding XSS explains why frameworks auto-escape rendered content
- Escaping-by-context is a simple, highly effective root fix
- Content-Security-Policy adds a strong second layer of defense
- HttpOnly cookies limit the blast radius even if XSS occurs
AI Mentor Explanation
XSS is like a fan slipping a fake public-address announcement card into the stack the announcer reads aloud without checking it, so the stadium speakers broadcast the attacker's message as if it were official. Every listener in the ground hears it as legitimate, because it came through the trusted announcer's microphone. That untrusted-content-read-as-if-official pattern is exactly how XSS smuggles a malicious script into a trusted page.
Step-by-Step Explanation
Step 1
Attacker injects malicious input
Untrusted text containing a script tag or event handler is submitted via a form, URL, or field.
Step 2
Application renders it unescaped
The server or client inserts that input directly into the page HTML without escaping special characters.
Step 3
Victim's browser executes it
The browser cannot distinguish injected script from legitimate page code, so it runs with full page privileges.
Step 4
Attacker harvests the result
The script can steal cookies, tokens, or make authenticated requests, sending data back to the attacker.
What Interviewer Expects
- Clear distinction between stored, reflected, and DOM-based XSS
- Understanding that the root cause is unescaped output, not just "bad input"
- Knowledge of context-aware output escaping and CSP as defenses
- Awareness that HttpOnly cookies limit damage even if XSS occurs
Common Mistakes
- Thinking input validation alone prevents XSS (output escaping is the real fix)
- Confusing XSS with SQL injection — different injection targets and defenses
- Believing client-side frameworks make XSS impossible by default (dangerouslySetInnerHTML-style escapes still exist)
- Forgetting DOM-based XSS, which happens entirely in client-side JS with no server involvement
Best Answer (HR Friendly)
“XSS is a security flaw where an attacker sneaks malicious code into a webpage, often through something like a comment box, and that code runs in other visitors' browsers as if it belonged to the real site. This can let an attacker steal login sessions or perform actions as the victim. Developers prevent it by properly escaping any content they display and using security headers like Content-Security-Policy.”
Code Example
// Unsafe: renders user input as raw HTML (vulnerable to XSS)
document.getElementById("comment").innerHTML = userComment
// Safer: treats input as plain text, not executable markup
document.getElementById("comment").textContent = userComment
// Server-side escaping example before templating
function escapeHtml(str) {
return str
.replace(/&/g, "&")
.replace(/</g, "<")
.replace(/>/g, ">")
.replace(/"/g, """)
}Follow-up Questions
- What is the difference between stored, reflected, and DOM-based XSS?
- How does Content-Security-Policy help mitigate XSS?
- Why does marking a cookie HttpOnly reduce the impact of XSS?
- Why is input validation alone not sufficient to prevent XSS?
MCQ Practice
1. What is the root cause of an XSS vulnerability?
XSS happens when untrusted input is inserted into a page without proper context-aware escaping, letting it run as code.
2. Which XSS type saves the malicious script on the server for every visitor?
Stored XSS persists the payload server-side (e.g., in a comment), serving it to every subsequent visitor.
3. What does marking a cookie as HttpOnly protect against?
HttpOnly cookies are inaccessible to JavaScript, so even a successful XSS script cannot read them.
Flash Cards
What does XSS stand for? — Cross-Site Scripting.
What is the root cause of XSS? — Untrusted input rendered into a page without proper context-aware escaping.
Name the three main XSS types. — Stored, reflected, and DOM-based XSS.
How does HttpOnly help against XSS? — It prevents JavaScript, including injected scripts, from reading that cookie.