XSS and CSRF: a locked door and open windows

The server generates the nonce and the browser checks it, so the attacker, who controls neither side, has nothing to work with.

When the browser parses the response, it copies each nonce into an internal slot for CSP checks, then wipes the attribute from JS reads:

document.querySelector('script[nonce]').nonce              // ""
document.querySelector('script[nonce]').getAttribute('nonce') // ""

With a 128-bit random regenerated per request, there's nothing left to read, duplicate, or brute-force. Nonce hiding shipped in Chrome 49 (2016), Firefox 31, Safari 11. Universal today.

eval family (eval, new Function, setTimeout(string)) is also blocked by default CSP since 'unsafe-eval' isn't on unless you ask for it.

Only breaks if you misconfigure: 'unsafe-inline' cancels nonce checks, 'unsafe-eval' opens eval, static or low-entropy nonce is replayable, 'strict-dynamic' can be leveraged via a controllable loader. All config bugs, not mechanism flaws.

X-Content-Type-Options and the Content-Type it protects are both set by your server when it sends a stored file back, not when the file is uploaded. They are two separate trips:

• Upload (a user sends you a file). The Content-Type on that request is whatever the uploader chose, so it is attacker-controlled. Don't store it and reuse it later.
• Serve-back (your server returns the file to a viewer). Here your server sets the Content-Type itself, normally from the file extension (.png becomes image/png), and adds nosniff. This response is where the decision happens.

nosniff tells the viewer's browser to trust the Content-Type from the serve-back and never re-guess it from the bytes. So it only protects you if that Content-Type is correct. Serve a malicious avatar.png as image/png and the browser treats it as an image (a broken one), never as a script. Serve it as text/html because you copied the uploader's value, and nosniff will trust that and render a page. The header only enforces your label, so the label has to be right first.

The victim is a third party: an attacker uploads a file with a script inside, your server stores it, and a different user opens its URL. Execution needs the file to be opened as a document (a direct navigation). Loaded through <img>, the same file only ever decodes as image bytes and never runs.

Putting a JWT or access token in memory (Zustand, React context, plain module variable) is better than localStorage, not safe from XSS. XSS runs in your origin. Any JS-reachable state is reachable:

// XSS payload, knowing the store
useAuthStore.getState().token
// or scanning the React fiber tree, or grabbing closures via DevTools

The advantages over localStorage are real but they're about limiting the damage, not invisibility:

• Harder for a generic XSS template. localStorage.getItem('token') works on every site. Reading a Zustand store needs knowledge of the store's reference, which varies per app. Drive-by XSS payloads collect 100% of localStorage tokens, much fewer in-memory ones.
• Once the user closes the tab, the token disappears along with it. Close tab or reload, XSS gone, attacker loses the handle. localStorage persists across reloads, and stolen tokens replay from any device until expiry.

Same logic as HttpOnly cookies: drop "permanent credential captured" down to "tab-lifetime session hijack." Combined with short-lived access tokens (5-15 min) and HttpOnly refresh cookies, the real damage window is small.

Foundation first, same as the JWT app: CSP nonce, framework auto-escape, and nosniff. An XSS getting in voids every cookie and CSRF layer below it, so treat the anti-XSS layer as the floor, not a step you climb to later. Everything numbered below hardens the cookie itself and assumes that foundation is already in place.

The numbered order then walks the cookie from naked to hardened. These steps are numbered, not lettered like the JWT ladder below, because each one stacks on the last: you finish with all of them, not one. That order follows implementation cost, not defense value. Two different axes, and they disagree:

So the ladder order is for retrofitting an existing app without breaking it: cheap hygiene first, the expensive high-value layer when you can schedule it. Starting a fresh project? Do CSP on day one.

0. Bare cookie. Everything is exposed: XSS can read it, CSRF can use it, and it travels in plaintext.

Set-Cookie: session=abc123

1. Lock the cookie down, and ship the free header while you are here. HttpOnly stops JS reading it, Secure keeps it off plaintext HTTP. nosniff is one line and belongs in this batch, even though it defends the script-execution layer covered in step 4.

Set-Cookie: session=abc123; HttpOnly; Secure; Path=/
X-Content-Type-Options: nosniff

XSS can no longer exfiltrate it. It can still use the session from inside the page, so this is a downgrade, not a cure.

2. Kill classic CSRF with SameSite. Cross-site sub-resource requests (the <img src="bank.com/transfer"> trick) stop carrying the cookie.

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/

Use SameSite=Strict for admin and money endpoints.

3. Add a CSRF token on state-changing requests, since SameSite has edge cases.

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="{{ csrfToken }}">
</form>

// server, on POST
if (req.body.csrf_token !== session.csrfToken) return res.status(403).end()

4. The foundation, written out. CSP nonce and framework auto-escape (nosniff already shipped in step 1). This is the floor from the top of this list. If you started a fresh project here, the box is already ticked and everything above was the cheap hygiene you layered on after.

Content-Security-Policy: script-src 'self' 'nonce-RANDOM'

<div>{userInput}</div>   // safe, the framework escapes it
// never feed user data to dangerouslySetInnerHTML / v-html / innerHTML

5. Reject foreign Origin on state-changing routes. Cheap second layer.

if (req.method === 'POST' && req.headers.origin !== 'https://bank.com') return res.status(403).end()

6. Re-auth on the dangerous stuff. Transfer money, change email, delete account: re-enter password or tap a hardware key. The only layer that still holds if XSS gets in.

Do the foundation before you touch the token. Everything about where the token lives (A, B, C below) only limits the damage once XSS is already in. One layer keeps XSS out in the first place, so it comes first.

D. The foundation: stop XSS from running at all. CSP nonce, framework auto-escape, nosniff, and re-auth on sensitive ops. A token sitting in localStorage behind solid CSP can be safer than a perfectly placed token with no CSP, because the second app still lets injected script run. This is the one layer that keeps the attacker out instead of just limiting the damage.

Content-Security-Policy: script-src 'self' 'nonce-RANDOM'
X-Content-Type-Options: nosniff

Then choose where the token lives. These are lettered, not numbered like the cookie ladder above, because you pick one, not all: A, B, and C answer the single question of where the token sits, and each replaces the one before. Pick the furthest you can reach.

A. Token in localStorage. The worst. One XSS line steals it, and it replays from any device until expiry.

localStorage.setItem('token', jwt)   // don't

B. Token in memory. A module variable or store, never persisted. It dies when the tab closes, so a stolen copy doesn't outlive the session. XSS can still read it while the tab is open. Replaces A.

let accessToken = null
function setToken(t) { accessToken = t }

C. Short-lived access token in memory, refresh token in an HttpOnly cookie. The access token lives 5-15 min in a memory variable; the refresh token goes somewhere JS can never read. A stolen access token expires in minutes, and the valuable long-lived credential stays out of reach. Replaces B.

Set-Cookie: refresh=...; HttpOnly; Secure; SameSite=Strict; Path=/auth/refresh

// silent refresh, the browser sends the refresh cookie on its own
const res = await fetch('/auth/refresh', { credentials: 'include' })
accessToken = (await res.json()).accessToken

The refresh cookie auto-attaches, so /auth/refresh has a CSRF surface of its own. SameSite=Strict on that one cookie closes it. You've shrunk CSRF from the whole app to a single endpoint.

The strongest JWT app is D plus C: keep XSS out, and if it ever gets in, make the token it can reach expire in minutes. No CSRF token is needed while auth stays in the header, since the JWT doesn't auto-attach. Any route still on cookie auth is a cookie app, defend it as one.