Frontend Beauty
ESC

Type to search the knowledge base.

Frontend Security Threat Model

Threat-model SPAs: assets, attackers, XSS/CSRF/supply-chain, and where frontend controls actually land.

intermediate3 min read
  • security
  • threat-model
  • xss
  • csrf
  • spa

A threat model answers: what are we protecting, from whom, and which controls matter? Frontend interviews often dump buzzwords; seniors map threats to concrete sinks and headers.

Docs: OWASP Threat Modeling, web.dev security, XSS.

Assets

Asset Why it matters
Session / tokens Account takeover
PII on screen / in memory Privacy, compliance
Actions (transfer, delete) Fraud
Integrity of UI Phishing inside your origin
Admin tools Privilege abuse

Attackers & capabilities

  1. Remote web attacker — hosts evil.com, phishes users.
  2. XSS present — runs JS as your origin.
  3. Network attacker — only relevant without HTTPS / with mixed content.
  4. Malicious dependency / tag — code inside your build or page.
  5. Abusive logged-in user — hits your UI in unexpected ways (still validate server-side).

STRIDE-ish for FE

Threat Frontend angle
Spoofing Open redirects, fake origin UX
Tampering Unsigned client state trusted by server ❌
Repudiation Client logs only — server audit
Info disclosure Tokens in storage, verbose errors
DoS Less FE; watch unbounded client loops
Elevation Hiding admin buttons ≠ authz

Server enforces authz. Hiding a button is UX, not security.

Control map

XSS → safe sinks, sanitization, CSP, Trusted Types, HttpOnly cookies
CSRF → SameSite, CSRF tokens, no GET mutations
Clickjacking → frame-ancestors
Transport → HTTPS, no mixed content
Supply chain → lockfiles, SRI, minimize tags
Data → don’t put secrets in bundles

SPA-specific notes

  • XSS is catastrophic with any client-readable token.
  • CSRF matters for cookie sessions.
  • postMessage and iframes expand the boundary — model them explicitly.
  • Offline caches can retain sensitive HTML — be careful with SW caches.

Lightweight process

  1. Draw trust boundaries (browser, your API, third parties).
  2. List entry points (URL params, forms, messages, embeds).
  3. List sinks (DOM, navigation, storage).
  4. Assign controls + residual risk.
  5. Revisit when adding payments, UGC, or new third parties.

Interview out-loud

“I threat-model assets like sessions and privileged actions, then map XSS, CSRF, clickjacking, transport, and supply-chain to controls. UI hiding isn’t authz — the API enforces. SPAs make XSS especially expensive if tokens are JS-readable.”

Reviewer prompts

  • What is the asset (session, PII, money movement)?
  • What is the attacker capability (web, XSS, network, dependency)?
  • Which control fails closed if misconfigured?
  • Is the server still enforcing authz?
  • Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides