đŸ›Ąïž Application Security CheatSheet

XSS (Cross-Site Scripting) Deep Dive

XSS happens when a website lets untrusted input become part of a page in a way that the browser interprets as active content (script/HTML/DOM behavior) instead of plain text.

In the wild: XSS survives refactors because it hides in UI glue code — the one template or markdown renderer everyone assumes is “already sanitized.”

Key idea: XSS is a browser interpretation bug. The server (or client code) accidentally tells the browser: “treat attacker-controlled text as code/markup”.

Why XSS exists (deep reason)

Browsers have a powerful “document runtime”: HTML is parsed into a DOM, CSS affects rendering, and JavaScript can read/modify the DOM and make network requests. The browser must decide what is data vs what is instructions.

XSS impact is often about session/account actions and data access in the user’s context, not “hacking the server”.

First-principles mental model

Think of XSS as a pipeline:

  1. Source: where untrusted data comes from (query params, stored comments, profile fields, external APIs).
  2. Transformation: how the app processes it (templating, sanitization, concatenation, markdown, rich text).
  3. Sink: where it is inserted (HTML, attributes, URLs, JS strings, DOM APIs like innerHTML).
  4. Context: what the browser thinks that sink means (text node vs attribute vs script vs URL).
experienced rule: “Escape is not universal.” XSS prevention is contextual output encoding plus reducing dangerous sinks.

Types / variants (and why they differ)

1) Reflected XSS

Plain: input comes in the request and shows up in the response immediately.

Deep: risk is highest in search pages, error pages, and any “echo” of user input. Often one request triggers it.

2) Stored XSS

Plain: input is saved (comment/profile) and later shown to others.

Deep: impact can scale because many users view the same stored content (feeds, admin panels, moderation tools).

3) DOM-based XSS

Plain: the server response is fine, but client-side JavaScript builds unsafe HTML/DOM from untrusted data.

Deep: sources include location, document.referrer, postMessage, and JSON returned by APIs; sinks include innerHTML, outerHTML, unsafe templating, and dynamic script insertion.

Interview line: “XSS classification is about where the unsafe merge happens: server reflection, stored rendering, or DOM sinks.”

Vulnerable vs secure code patterns (Node.js)

Vulnerable pattern (minimal)

// Node/Express (concept example)
app.get("/search", (req, res) => {
  const q = String(req.query.q || "");
  // ❌ Vulnerable: untrusted data is merged into HTML without contextual escaping
  res.set("Content-Type", "text/html; charset=utf-8");
  res.send(`<h1>Search</h1><p>You searched for: ${q}</p>`);
});

Secure pattern 1: escape for HTML context

// ✅ Escape for HTML text context (minimal helper)
function escapeHtml(s) {
  return String(s)
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#39;");
}

app.get("/search", (req, res) => {
  const q = String(req.query.q || "");
  res.set("Content-Type", "text/html; charset=utf-8");
  res.send(`<h1>Search</h1><p>You searched for: ${escapeHtml(q)}</p>`);
});

Secure pattern 2: default-escaping templates + strict sinks

// ✅ Prefer a templating engine that auto-escapes by default
// Example idea: res.render("search", { q }) where template uses escaped interpolation.
// Also: do NOT use dangerous DOM sinks (innerHTML) on the client unless necessary.
Reality check: Escaping must match the context. HTML text escaping is not the same as attribute escaping, URL validation, or JS string encoding.

Where XSS still happens in modern stacks

Detection workflow (experienced-style, systematic)

The goal is to determine (1) reflection/storage and (2) context, then validate defensively.

Step A — Find candidate sources

Step B — Identify sinks & context

Step C — Validate defenses

Interview framing: “I don’t start with payloads. I start with context discovery and defense validation: encoding, sanitization, and CSP.”

Safe validation (defensive verification only)

Goal: demonstrate unsafe interpretation with minimal risk and no harmful actions. Avoid exfiltration, credential access, or destructive behavior.
  1. Baseline: record the normal response and where the input appears (HTML/text/attribute/DOM).
  2. Context proof: demonstrate that the browser interprets the input as active content (not just text), using a harmless indicator in a controlled environment.
  3. Scope: confirm whether it’s reflected, stored, or DOM-based; confirm which users are impacted.
  4. Defense checks: confirm encoding/sanitization behavior; capture CSP headers and whether inline scripts are allowed.
  5. Evidence: capture request/response, rendered DOM location, and security headers (CSP, cookies) to support root cause and fix.
Do not provide or use copy/paste exploit strings in interviews or production systems. Describe methodology and evidence instead.

Exploitation progression (attacker mindset)

This is a real-world process explanation (no step-by-step exploit instructions). Attackers usually escalate from “can I influence rendering?” to “can I reach high-value user sessions?” by following trust boundaries and defense gaps.

Phase 1: Find a reliable merge point

Phase 2: Evaluate defenses and constraints

Phase 3: Move to higher-impact paths

Phase 4: Chain within app behavior

Interview takeaway: XSS exploitation is about context + constraints: where data lands, what the browser allows, and what the user session can do.

Tricky edge cases & bypass logic (conceptual)

experienced tip: When you see “rich content”, ask: “Where is it rendered, under which origin, with what sanitizer and CSP?”

Confidence levels (how sure are you?)

ConfidenceWhat you observedWhat you can claim
Low Suspicious reflection/storage but unclear context; inconsistent behavior “Potential XSS indicators; needs context confirmation and repeatability”
Medium Repeatable unsafe rendering in a specific context, but constraints limit impact “Likely XSS; untrusted input is interpreted as active content under some conditions”
High Repeatable proof of active interpretation with clear affected users/scope and strong evidence “Confirmed XSS with demonstrated impact scope and clear root cause/fix guidance”

Fixes that hold in production

1) Contextual output encoding (default)

2) Minimize dangerous sinks

3) Strong Content Security Policy (CSP)

4) Cookie hardening + sensitive-action defenses

Practical priority order: fix the sink (encode/sanitize) → remove dangerous patterns → add CSP defense-in-depth → harden sensitive workflows.

Regression prevention (how to prevent regressions)

Interview-ready summaries (60-second + 2-minute)

60-second answer

XSS is when untrusted input is rendered so the browser interprets it as active content instead of text. I classify it as reflected, stored, or DOM-based, and I focus on context: HTML, attributes, URLs, or JS. The primary fix is contextual output encoding and avoiding dangerous DOM sinks; for rich text I sanitize with strict allow-lists. Then I add defense-in-depth with a strong CSP and regression tests to prevent reintroduction.

2-minute answer

I treat XSS as a trust-boundary mistake between data and instructions in the browser. First I identify where input is merged into output and in what context. Then I verify defenses: correct contextual escaping, safe template defaults, sanitizer behavior for rich content, and CSP strength (nonces/hashes, no unsafe-inline). I also consider impact scope: who views it (stored vs reflected), and whether privileged users are exposed (admin/support tooling). For fixes, I prioritize eliminating unsafe sinks and standardizing encoding/sanitization, then add CSP as defense-in-depth. Finally I prevent regressions with code review rules, tests, and monitoring for header changes.

Checklist (quick review)

Remediation playbook

  1. Contain: disable the risky rendering path (raw HTML) or limit exposure (feature flag, restrict viewers) until fixed.
  2. Fix root cause: apply contextual output encoding at the sink; remove dangerous DOM insertion patterns.
  3. Sanitize where needed: if rich text is required, use strict allow-lists and test sanitizer behavior on edge inputs.
  4. Harden platform: deploy a strong CSP (nonces/hashes), review third-party scripts, and tighten sources.
  5. Prevent regressions: add tests, lint rules, and code review gates for raw HTML and DOM sinks.
  6. Verify: re-test the original flow and search for similar patterns across the codebase (same helper/template/sink).

Interview Questions & Answers (Easy → Hard)

How to use: Start with a simple explanation, then add experienced depth: context, constraints, and defenses (encoding/sanitization/CSP).

Easy

  1. What is XSS?
    A: Plain: when a site lets attacker-controlled content run in a user’s browser. Deep: it’s a failure to keep untrusted input as data; the browser interprets it as active content under your site’s origin. Fix is contextual output encoding + safer sinks.
  2. Reflected vs stored vs DOM XSS?
    A: Plain: reflected is immediate echo, stored is saved then shown, DOM is client-side rendering. Deep: the difference is where the unsafe merge happens (server response vs persistence vs DOM sinks).
  3. Why is XSS dangerous?
    A: Plain: it can make the browser do actions as the victim. Deep: scripts run under your origin and can interact with the app’s APIs and UI; impact depends on permissions and defenses like HttpOnly and CSP.
  4. Best primary defense?
    A: Plain: output encoding. Deep: contextual encoding at the sink (HTML/attr/URL/JS) plus avoiding dangerous DOM sinks.
  5. Is input validation enough?
    A: Plain: no. Deep: validation reduces risk but doesn’t guarantee safe browser interpretation; encoding/sanitization at render time is the reliable control.
  6. What is CSP in one line?
    A: Plain: a browser rule that limits what scripts can run. Deep: a defense-in-depth layer; strong CSP uses nonces/hashes and avoids unsafe-inline to reduce exploitability even if a rendering bug exists.

Medium

  1. Scenario: Search page reflects a query parameter. What do you do first?
    A: Plain: find where it appears and ensure it’s treated as text. Deep: determine the context (HTML/attr/JS/DOM), verify correct encoding, and check CSP/cookie flags. I describe evidence and fixes, not payload steps.
  2. Scenario: A comment system supports “bold/links”. How do you keep it safe?
    A: Plain: sanitize what you allow. Deep: use a strict allow-list sanitizer, avoid letting user content become raw HTML, and test sanitizer behavior across edge cases and DOM normalization.
  3. How do you explain “contextual encoding” simply?
    A: Plain: escape depends on where the text goes. Deep: HTML text, attributes, URLs, and JS strings have different parsing rules; using the wrong encoding can still leave an execution path.
  4. Follow-up: Why do frameworks help but not fully solve XSS?
    A: Plain: they’re safer by default. Deep: risk returns when developers bypass defaults (raw HTML rendering, unsafe DOM APIs, custom template helpers, legacy pages).
  5. Scenario: Admin/support tools render user-submitted content. Why is that high risk?
    A: Plain: privileged users may view it. Deep: stored XSS in admin panels can become privilege escalation in-app; fix is consistent encoding/sanitization and segregating risky rendering paths.
  6. Follow-up: How do you verify CSP is effective?
    A: Plain: check headers and behavior. Deep: confirm it blocks inline execution unless nonced/hashed, avoid unsafe-inline, and ensure script-src is tight; use report-only during rollout then enforce.
  7. Scenario: The app embeds JSON into HTML. What’s the risk?
    A: Plain: it can break out of the intended context. Deep: improper serialization can turn data into executable context; use safe serializers and avoid inline script data blobs when possible.
  8. Follow-up: How do you prioritize fixes?
    A: Plain: fix the rendering point first. Deep: remove/replace unsafe sinks, standardize encoding/sanitization, then add CSP and tests for defense-in-depth and regression prevention.

Hard

  1. Scenario: Stored XSS is only visible to the user who posted it. Is it still a concern?
    A: Plain: it can be, depending on who views it. Deep: even “self-XSS” might become real if content is reused elsewhere (admin review, exports, notifications). I scope viewers and secondary render paths.
  2. Scenario: Strong CSP exists, but XSS still reported. How is that possible?
    A: Plain: CSP reduces impact, not always eliminates it. Deep: misconfigurations, overly broad sources, allowed inline scripts, or non-script injection impacts can remain; plus DOM-based issues may still change page behavior even if script execution is limited.
  3. Scenario: The product requires user HTML (email templates). How do you design it safely?
    A: Plain: restrict what’s allowed. Deep: use strict allow-lists, separate rendering origin if possible, sanitize server-side, and ensure previews are isolated; enforce CSP and avoid mixing with privileged app contexts.
  4. Follow-up: What’s the most common “experienced miss” in XSS fixes?
    A: Plain: escaping in the wrong place. Deep: encoding at input time instead of output time, or applying HTML escaping to a JS/attribute context; also forgetting secondary sinks like exports, emails, and admin tooling.
  5. Scenario: Multi-tenant app: could XSS become a tenant-escape issue?
    A: Plain: yes if content crosses boundaries. Deep: if tenant content is rendered in shared admin views or cross-tenant dashboards, XSS could target privileged operators; I verify tenant isolation and viewer roles.
  6. Follow-up: How do you prevent reintroducing XSS across many teams?
    A: Plain: standardize safe patterns. Deep: central helpers for encoding/sanitization, ban raw HTML helpers by policy, lint rules for dangerous sinks, secure component libraries, and tests for critical templates.
  7. Scenario: DOM-based XSS from postMessage. What do you check?
    A: Plain: trust and validation. Deep: validate origin, validate message schema, and ensure the handler does not pipe message data into HTML sinks; use safe DOM APIs and strict parsing.
  8. Follow-up: How do you report XSS safely?
    A: Plain: show minimal evidence. Deep: provide request/response, render context, affected users/scope, security headers, and the exact sink/root cause with recommended fix and regression test idea—without harmful scripts or data exposure.
Safety note: for understanding +
← Back: SQLi Next: SSRF →