Part II — The Shield · Lesson 3.1
Security Overview
In one lineEverything the browser receives is attacker-reachable — your job is to shrink what a breach can reach.
Where you've seen itAny page with an analytics tag. That third-party script runs with exactly the same powers as your own application code.
Diagram
ATTACK SURFACE OF A BROWSER APP
┌──────────────────────── The browser tab ─────────────────────────┐
│ │
│ Your JS ── same origin ──► cookies, localStorage, DOM, fetch │
│ ▲ │
│ │ XSS (3.2) injected script gets ALL of the above │
│ │ 3rd-party (3.7) npm packages + CDN tags, same powers │
│ │ iframe (3.3) you embedded, or you got embedded │
│ │
└───────────────┬──────────────────────────────────────────────────┘
│ every request carries cookies automatically
▼ ← CSRF (3.15) rides this
┌──────────────────────────────────────────────────────────────────┐
│ Your server ── SSRF (3.10) ──► internal network │
│ ── SSJI (3.11) ──► code execution │
└──────────────────────────────────────────────────────────────────┘THE DEFENCE LAYERS — each one assumes the one above failed
1. Don't trust input validate + sanitize (3.9)
2. Don't trust output escape by context (3.2)
3. Don't trust scripts CSP + SRI (3.4, 3.13)
4. Don't trust embeds frame-ancestors, sandbox (3.3, 3.12)
5. Don't trust the wire HTTPS + HSTS (3.6)
6. Don't trust yourself no secrets in the bundle (3.5)How it works
- Enumerate what the attacker wants: session cookies, personal data, the ability to act as the user.
- Enumerate the ways in: your input fields, your URLs, your dependencies, your embeds, your API.
- Assume one layer fails and ask what the blast radius is. That question is the whole discipline.
- Prefer configuration over code — a header applies to every route; a code fix applies to one.
Trade-offs
| Principle | In practice |
|---|---|
| Defence in depth | Escape output and ship a CSP |
| Least privilege | HttpOnly cookies, scoped tokens, Permissions-Policy |
| Fail closed | Unknown input rejected, not "cleaned up" |
| Never trust the client | Every check re-run on the server |
Interview angle
"How do you think about security on the frontend?"
- Name the surfaces — injection, third-party code, embedding, transport, and the client's inability to keep secrets.
- Say the frontend can only reduce risk; authorisation is always re-checked server-side.
- Lead with the two highest-leverage moves: contextual output escaping and a strict CSP.
Recap
- Injected code inherits every power your own code has.
- Layer defences so a single failure isn't a breach.
- Headers scale better than fixes, because they cover routes you forgot.