Q026: XSS, CSP and Browser Security Controls

What Interviewers Want To Evaluate

This question tests whether you understand client-side security beyond "sanitize input." Interviewers want reflected, stored, and DOM-based XSS, output encoding, dangerous sinks, Content Security Policy, cookies, tokens, and framework limitations.

For senior roles, the strongest answer connects XSS prevention to architecture, review habits, and defense in depth.

Short Interview Answer

XSS happens when attacker-controlled content executes as JavaScript in a user's browser. Prevention starts with context-aware output encoding, avoiding dangerous HTML sinks, sanitizing trusted rich text, and keeping user data out of executable contexts. CSP adds defense in depth by restricting where scripts can load from and whether inline scripts can run. HttpOnly cookies reduce token theft from XSS, but they do not prevent XSS itself.

Detailed Interview Answer

XSS is dangerous because malicious JavaScript runs with the user's origin privileges. It can read accessible page data, make authenticated requests, alter the UI, steal non-HttpOnly tokens, and perform actions as the user.

Modern frameworks escape text by default, but applications can reintroduce risk through raw HTML rendering, markdown, URL injection, third-party scripts, unsafe templates, browser extensions, and DOM APIs.

Deep Technical Explanation

Common categories are:

reflected XSS -> payload comes from request and appears in response
stored XSS -> payload is saved and shown later
DOM XSS -> client-side code writes unsafe data into executable DOM

Context matters. Escaping for HTML text is different from escaping for URLs, attributes, CSS, or scripts.

Dangerous Sinks

Risky APIs include innerHTML, outerHTML, insertAdjacentHTML, unsafe markdown rendering, string-built scripts, and URL assignments without protocol validation.

React escapes text by default, but dangerouslySetInnerHTML bypasses that protection.

Content Security Policy

CSP is an HTTP response header that restricts what the browser can execute or load. It can limit script sources, block inline scripts, require nonces, restrict frames, and report violations.

CSP is defense in depth. It reduces blast radius, but it should not be the only protection.

Code Example

// Safer: React renders text, not HTML.
function Comment({ body }: { body: string }) {
  return <p>{body}</p>;
}

// Risky unless sanitized by a trusted HTML sanitizer.
function RichText({ html }: { html: string }) {
  return <article dangerouslySetInnerHTML={{ __html: html }} />;
}

Architecture Discussion

Security should be built into content pipelines. If the product supports rich text, define one sanitizer and one rendering path. Do not let every feature invent its own HTML handling.

Third-party scripts need review. They run with significant access to the page.

Trade-Offs

Rich content improves product experience but increases risk. Sanitization, allowlists, preview pipelines, and CSP make it safer but require ownership.

Strict CSP can break legacy code that relies on inline scripts. That is usually a signal to modernize the script model.

Common Mistakes

A common mistake is saying React prevents XSS. React reduces common text injection risk, but applications can still create XSS.

Another mistake is storing access tokens in localStorage and assuming CSP will fully protect them.

Real Production Story

A markdown preview feature can become an XSS source if it allows raw HTML or unsafe links such as javascript: URLs. The fix is a trusted sanitizer, protocol validation, and tests with known payloads.

Enterprise Example

In a CMS-backed marketing platform, content editors may embed rich content. The platform needs server-side sanitization, rendering constraints, CSP, preview checks, and incident response for unsafe embeds.

Performance Discussion

Security tooling can affect loading if it adds heavy sanitization to every render. Sanitize at ingestion or cache sanitized output when appropriate.

Security Considerations

Use HttpOnly, Secure, SameSite cookies for session tokens where appropriate. Avoid storing sensitive tokens in JavaScript-readable storage. Add CSP, dependency review, and output encoding.

Senior Engineer Perspective

A senior engineer should discuss dangerous sinks, context-aware output encoding, CSP, token storage, and review process.

Lead Engineer Perspective

A lead should define security standards for rich text, third-party scripts, CSP rollout, security tests, and production monitoring.

Revision Notes

XSS is attacker-controlled script execution in your origin. Prevent it through safe rendering, encoding, sanitization, and defense-in-depth controls like CSP.

Key Takeaways

Framework escaping helps, but architecture and review discipline prevent real production XSS.

Follow-Up Questions

1. What is reflected XSS?
2. What is stored XSS?
3. What is DOM-based XSS?
4. Why is innerHTML risky?
5. Does React prevent all XSS?
6. What does CSP do?
7. What is a CSP nonce?
8. Why are HttpOnly cookies useful?
9. Why is localStorage risky for tokens?
10. How would you design safe rich text rendering?

How I Would Answer This In A Real Interview

I would say XSS occurs when untrusted content becomes executable JavaScript in the user's browser. Then I would describe prevention: avoid dangerous sinks, rely on framework escaping for text, sanitize rich HTML, validate URLs, protect tokens, and use CSP as defense in depth.

Then I would emphasize that CSP reduces blast radius but does not replace safe rendering.