Your browser is a
shared space.

01Origin vs site — the two boundaries

in one line an origin is scheme + host + port and must match exactly; a site is looser — the same registrable domain, whatever the subdomain or port.

Almost every rule below is enforced at one of two boundaries, and they are not the same. Getting them mixed up is where most “why isn’t my cookie shared?” bugs come from. Compare a pair:

the practical upshotYour front-end host calling your API host is cross-origin, same-site. That needs a CORS allow-list and a cookie Domain attribute — not SameSite=None. Loosening SameSite there buys nothing and opens the cross-sitefetch() you wanted blocked.

02Navigation vs subresource — did the address bar change?

in one line a top-level navigation moves the whole tab and you can see where you landed; a subresource request happens invisibly, and the page that fired it reads the reply.

Every SameSite explanation leans on the phrase “top-level GET navigation” and never defines it. It’s the distinction the whole feature is built on — so here it is, side by side. Step both columns together:

<a href="bank.com">
  click me
</a>

<script>
  fetch("bank.com/balance",
    {credentials:"include"})
</script>

03Cookies — the wristband

in one line a cookie is a wristband that says “this is a logged-in user”; three flags decide who can copy or abuse it.

A cookie proves you’re logged in. Three flags protect it, each against a different attack. Set them below and watch what each choice blocks or exposes — the Set-Cookie line is exactly what you’d send.

the rule of thumbFor a normal login cookie, ship Secure; HttpOnly; SameSite=Lax. Reach up to Strict for admin/banking; down to None only for genuine cross-site needs (and then add a CSRF token).

04SameSite — Strict, Lax, None in full

in one line three places to draw one line: how far the cookie still rides when the request comes from another site.

With both boundaries in hand, the three values are simple. Pick one, then pick a situation — the matrix stays on screen so you read the cell in context:

the trap that breaks loginsAn SSO / OIDC flow sets a short state / PKCE cookie, sends the user to the identity provider, and the provider redirects them back to your /callback. That last hop is a top-level GET navigation arriving from another site. UnderStrict the cookie is withheld, the callback can’t verify its own PKCE challenge, and login fails. Under Lax it works — that case is exactly what Lax was designed for.

05XSS — someone else’s script on your page

in one line an attacker sneaks JavaScript onto your page; it runs as you and can read the DOM, cookies, and act on your behalf.

XSS is the big one. The classic delivery is a stored comment that’s saved raw and rendered unescaped. Step through it:

Two things almost every write-up of this gets wrong — and the second one changes what you go and fix:

One more thing, because the name actively misleads: it points at a boundary that isn’t the one being crossed. Three tabs, three different answers —

06CSRF — a forged request that rides your session

in one line another site makes your browser fire a request at a site you’re logged in to; your cookie tags along and the action runs as you.

CSRF needs no script on your page and steals nothing — it borrows your session for one request. Step through it:

07CSP — the safety net under XSS

in one line a Content-Security-Policy header whitelists where scripts, styles, and frames may come from — so even an injected <script> won’t run.

A CSP is your backstop: escaping can slip, but CSP still refuses to run code from anywhere you didn’t allow. Here are the everyday directives — then try a script-src value:

08Nonce — allowing inline script safely

in one line a random one-time token that marks YOUR inline scripts as trusted, so an injected script (which can’t guess it) is refused.

Sometimes you truly need an inline <script>. Instead of 'unsafe-inline' (which trusts everything), stamp your own scripts with a nonce:

the grown-up version — 'strict-dynamic'Add 'strict-dynamic' and the nonce stops being just an inline-script trick: any script you noncedly trust may load further scripts, and the browser ignores your host allow-list entirely. That’s the point — host allow-lists age badly (a CDN you allowed today hosts someone’s JSONP endpoint tomorrow, and your policy is bypassed). One nonce, no allow-list to maintain, and it keeps working when a vendor changes their bundle — see the SRI section for what that costs you.

09Framing & clickjacking — who can put you in an iframe

in one line clickjacking hides your real site in an invisible iframe over a fake button; you decide who may frame you with frame-ancestors.

Two directions, easy to mix up: frame-src = what YOU embed; frame-ancestors = who embeds YOU. The second stops clickjacking:

10CORS — how a hacker leverages a loose policy

in one line CORS decides whether another site may READ your API’s response; misconfigure it and evil.com reads your logged-in users’ data.

CORS is widely misunderstood — it’s not a lock on the request, it’s a rule on who may read the reply. Here’s the attack when it’s too loose:

11SRI — pinning the code your CDN serves

in one line Subresource Integrity adds a hash of the exact file you expect; if a hacked CDN swaps it, the hash won’t match and the browser blocks it — and it blocks a legitimate update just as hard.

You don’t control the CDN serving your lib.js. SRI makes that safe — pin the file’s hash. Then try the third toggle, the one most write-ups skip:

openssl dgst -sha384 -binary lib.js | openssl base64 -A

“can a nonce rescue this?” — partly, and know what you tradeThey answer different questions, so they are not substitutes. SRI asks “is this the exact file I reviewed?” — integrity of content. A nonce asks “did my own server put this tag on the page?” — authenticity of inclusion.

So a nonce does fix the breakage: with script-src 'nonce-r4nd0m' 'strict-dynamic' you stop pinning bytes and stop maintaining a host allow-list, the vendor updates freely, and an injected <script> is still refused because the attacker can’t guess the nonce. Your XSS protection is intact and your page stops breaking.

What you give up is precisely the thing SRI was bought for: if that CDN is compromised, the nonce’d tag loads the malicious file happily — the tag is genuinely yours, so the nonce is genuinely valid. A nonce cannot see inside the file. Nonce defends against an attacker injecting a tag into your page; SRI defends against the file at the other end of a tag you wrote. Pick by which threat is real for that asset — and for anything you can self-host, self-host it and the question disappears.

12HSTS — force HTTPS, kill the downgrade

in one line HSTS tells the browser “only ever talk to me over HTTPS”, so an attacker can’t strip the first http request down to cleartext.

HTTPS encrypts the wire — but only if you actually reach it. HSTS stops an attacker downgrading your first plain request. Step through the attack:

13The headers, all together — a ship-it baseline

in one line one response can carry every lock at once; here’s the exact header set this very site sends.

Each lock above is one HTTP response header. Set them together and you’ve covered the common client-side attacks — including the three quiet ones: X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.

X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' …;
  style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self' data: …;
  connect-src 'self' …; frame-ancestors 'none'; base-uri 'self';
  form-action 'self'; object-src 'none'; upgrade-insecure-requests