Security Interview Talking Points
Frontend security interview map — XSS, CSRF, CSP, cookies, supply chain — practical talking points without fear-mongering.
- interview
- security-interview
Frontend security interviews check whether you threat-model the browser, not whether you can recite OWASP alphabet soup. Own XSS and auth cookie realities cold.
Threat model overview: Frontend security threat model.
What interviewers score
- XSS — sources, sinks, defenses
- Auth session — cookie flags, token storage
- CSRF — when it applies
- CSP / headers — defense in depth
- Supply chain — dependencies, SRI
XSS (must master)
| Topic | Can you… | Learn |
|---|---|---|
| Definition | Attacker runs script in victim origin | XSS |
| Sinks | innerHTML, eval, javascript: URLs, dangerous React HTML |
dangerouslySetInnerHTML |
| Defense | Encode/escape, framework auto-escape, sanitize HTML policies | XSS prevention checklist |
| CSP | Reduce blast radius; not only control | CSP |
| Trusted Types | Lock DOM sinks in supporting browsers | Trusted Types |
Out loud: “React escapes text content by default; risk returns with dangerouslySetInnerHTML, user-built URLs, and eval-like patterns.”
Cookies, tokens, sessions
| Topic | Can you… | Learn |
|---|---|---|
| Cookie flags | HttpOnly, Secure, SameSite |
Secure cookie flags |
| JWT storage | Why localStorage is XSS-sensitive | JWT storage pitfalls |
| Session UX | Expiry, refresh, multi-tab | Auth session UX |
| HTTPS | Mixed content failures | HTTPS & mixed content |
Prompt: “Where do you store access tokens?” — Prefer short-lived access + httpOnly refresh/session cookie patterns; discuss CSRF if cookies are used for auth.
CSRF
| Topic | Can you… | Learn |
|---|---|---|
| When | Cookie-authenticated state-changing requests | CSRF for SPAs |
| Mitigations | SameSite, CSRF tokens, custom headers, re-auth |
Out loud: “If auth is a bearer header from JS memory, classic CSRF is weaker; XSS becomes the bigger issue.”
Browser platform controls
| Topic | Can you… | Learn |
|---|---|---|
| Same-origin | What is protected | Same-origin policy |
| CORS | Not an authz system for servers | CORS |
| iframe sandbox | Constrain embeds | Sandboxing iframes · iframe sandbox |
| postMessage | Validate origin; don’t trust data |
postMessage security |
| Clickjacking | Framing; CSP frame-ancestors |
Clickjacking |
| Open redirects | Validate next URLs | Open redirects · Safe URL handling |
Supply chain & secrets
| Topic | Can you… | Learn |
|---|---|---|
| Dependencies | lockfiles, audits, least install | Supply chain risk |
| SRI | Pin CDN scripts | Subresource integrity |
| Secrets | No API keys in frontend bundles | Secrets in bundles |
| Rate limits | UX for 429 | Rate limiting UX |
Classic Q&A directions
| Question | Strong direction |
|---|---|
| Stored vs reflected XSS? | Persistence in data store vs crafted link |
| Is CORS a security boundary for your API? | Server must authz; CORS is browser-enforced |
| Why HttpOnly? | JS cannot read cookie → mitigates token theft via XSS (not all XSS impact) |
| How does CSP help? | Whitelist script sources; block inline unless hashed/nonced |
| Markdown preview XSS? | Sanitize HTML; CSP; careful link protocols |
Threat-model sketch (use in design rounds)
For a notes app:
- Assets — notes, session, payments
- Entry points — HTML injection in notes, OAuth redirects, embeds
- Abuses — account takeover, data exfil, malware distribute
- Controls — encode, CSP, cookie flags, CSRF tokens, audit deps
Footguns
- “We’re safe, we use React”
Access-Control-Allow-Origin: *with credentials fantasies- Disabling security headers to “fix” local dev permanently
- Logging PII tokens to third-party analytics
Related on this site
Further reading
Security answers should sound like engineering controls, not movie hacks. Name the attacker capability, then the mitigation.