FSD Frontend System Design

Part II — The Shield · Lesson 3.2

Cross-site Scripting (XSS)

In one lineUntrusted text becomes executable code, and that code owns the user's session.

Where you've seen itA comment box that stores whatever you type and renders it back as HTML to every other reader.

  • Time18 min
  • DiagramStored vs Reflected vs DOM-based flows
  • Chapter3 · Security

Diagram

diagram
THREE FLAVOURS — same result, different path

  STORED (persistent)          worst: hits every visitor
    attacker ──► POST comment ──► database ──► rendered to all users
                                                       │
                                                  script runs

  REFLECTED (in the URL)       needs a click on a crafted link
    attacker ──► sends link ──► victim ──► server echoes ?q= into HTML
                                                       │
                                                  script runs

  DOM-BASED (never reaches server)
    attacker ──► #hash in URL ──► your JS reads location.hash
                                       └─► innerHTML = value
                                                  script runs
diagram
WHAT THE INJECTED SCRIPT GETS — the same origin as you

  document.cookie          → session hijack (unless HttpOnly)
  localStorage             → tokens you stored there
  fetch('/api/transfer')   → acts AS the user, cookies attached
  DOM rewrite              → fake login form on the real domain

  There is no partial XSS. Execution means full compromise of the origin.
diagram
ESCAPING IS CONTEXT-DEPENDENT — one function is not enough

  <div>HERE</div>              → HTML escape:  & < > " '
  <a href="HERE">              → URL encode + block javascript:
  <div onclick="HERE">         → never put user data here
  <script>var x = "HERE"</script> → JSON encode, still risky
  <style>color: HERE</style>   → CSS escape

How it works

  1. Untrusted data reaches a sink that parses HTML or evaluates code: innerHTML, outerHTML, document.write, eval, dangerouslySetInnerHTML, srcdoc.
  2. The browser cannot tell your markup from the attacker's — it's all one document.
  3. Escape on output, by context, not on input. Frameworks (React, Vue, Angular) escape text nodes by default; the holes are the explicit opt-outs.
  4. For genuine rich text, sanitize with an allowlist (DOMPurify), never with a blocklist or a regex.
  5. Add CSP as the second layer so an injection that gets through still can't execute.
js
// ✗ sink
el.innerHTML = comment;

// ✓ text, never parsed as markup
el.textContent = comment;

// ✓ rich text that must keep <b>, <i>, links
el.innerHTML = DOMPurify.sanitize(comment);

Trade-offs

DefenceStopsDoesn't stop
Framework auto-escaping95% of casesdangerouslySetInnerHTML, href
DOMPurify allowlistRich-text injectionBugs in your own sink usage
CSP script-srcExecution of injected scriptThe injection itself
HttpOnly cookiesCookie theftRequests made as the user

Interview angle

"React escapes everything. Are you safe from XSS?"

  • No — dangerouslySetInnerHTML, href={userInput} with a javascript: URL, and ref DOM writes all bypass it.
  • Server-rendered JSON embedded in a <script> tag is a second common hole.
  • Layer it: escape by context, sanitize rich text with an allowlist, and ship a CSP for the case you missed.

Recap

  • Any path from untrusted input to an HTML/JS sink is XSS.
  • Escape on output and by context; sanitize with an allowlist when markup is required.
  • CSP and HttpOnly limit the damage of the injection you didn't catch.