Frontend Security
XSS, CSRF, the same-origin policy, CORS, CSP, clickjacking, third-party scripts and supply chain — the browser-side half of a problem the server cannot solve alone.
The origin as the unit of trust, the renderer as a sandbox, and four separate mechanisms answering four separate questions — mixing them up is why security fixes so often do nothing.
Embedding is allowed, reading is not — and the gap between "the request was sent" and "your code may see the answer" is where most browser security confusion lives.
Untrusted content becomes executable content. Your framework already escapes text interpolation — so every XSS in a modern application is at the exact place someone opted out.
Escaping and sanitization are different operations solving different problems — and when you genuinely must render HTML, allowlist it, at render time, with something you did not write.
The browser attaches credentials to requests automatically, including ones another site caused. That helpfulness is the vulnerability, and it is why the defence has to be explicit.
A browser policy about whether script may read a cross-origin response. Not authentication, not a firewall, and not relevant to anything that is not a browser — plus the error message that lies to you.
A browser-enforced allowlist for what your page may execute and load. It caps the damage of an injection you missed — and `unsafe-inline` in the script directive turns the whole thing off.
Your interface, rendered inside someone else's page, with their content on top. The defence is one response header — and the wrong version of it locks out keyboard users instead.
A script tag grants full authority over your page. There is no partial trust, and the dependency you never chose is running in the same context as your login form.