Where Do Tokens Live? XSS, CSRF and the Storage Trade-off

A credential is data that proves who you are, such as a session ID or a token. This lesson separates "I store the JWT in localStorage because the tutorial did" from "here is the threat model and the trade-off". (A threat model is a written list of who might attack you, how, and what you do about it.) You need to know two attacks and four patterns.

The two attacks

XSS: cross-site scripting

XSS (cross-site scripting) is an attack where the attacker gets their JavaScript to run on your origin. (An origin is the scheme, host and port of a site, such as https://app.example.com.) This can happen through user content that was not cleaned, a weak dependency, a hacked third-party script, or a place in the DOM (the page as a tree of objects that JavaScript can change) that you forgot to protect. From then on, the browser treats the script as if it were you.

What the script can do:

• Read anything JavaScript can read: localStorage and sessionStorage (browser stores for text), cookies that are not HttpOnly (HttpOnly is a cookie setting that hides the cookie from JavaScript), tokens in variables, and the DOM (including personal data on the screen).
• Act as the user: call your API with fetch. The browser adds the session cookie automatically, HttpOnly or not.
• Change the page: show a fake login form and capture the password.

CSRF: cross-site request forgery

CSRF (cross-site request forgery) is an attack where the attacker does not run code on your site. Instead, they make the victim's browser send a request to your site from another place. The browser helpfully adds the cookies.

<!-- On evil.example, while the victim is logged in to bank.example --><form action="https://bank.example/transfer" method="POST" id="f">  <input name="to" value="attacker" /><input name="amount" value="5000" /></form><script>document.getElementById("f").submit()</script>

The attacker can cause an action, but cannot read the response. (The same-origin policy blocks reading. This is a browser rule that stops a page from one origin from reading data that belongs to another origin.) So CSRF aims at endpoints that change data and trust only "the cookie is there".

What each storage choice exposes

Read the HttpOnly row with care. It is the most misunderstood fact in this topic: HttpOnly stops token theft, not account abuse. An XSS script cannot take the cookie away. So the attacker cannot use it later from another place. But the script can still do actions while the victim's tab is open. HttpOnly makes the damage smaller. Preventing XSS is the real control.

Defending against CSRF (when you use cookies)

Use several layers. No single one is the full answer.

1. SameSite cookies. SameSite is a cookie setting that controls whether the cookie is sent when the request starts from another site. (A site is the registrable domain, such as example.com, with all its subdomains.)
   • Lax: the cookie is not sent on cross-site POST, fetch, iframes (pages embedded inside a page) or images. It is sent when the user goes to your site from another site with a safe method such as GET (for example, by clicking a link). This move is called a top-level navigation: the address bar changes.
   • Strict: the cookie is never sent on cross-site requests. This includes clicking a link from another site, so the user may look logged out when they arrive.
   • None: always sent. It requires Secure. Use it only when you really need cross-site cookies.
2. CSRF tokens. A CSRF token is a random secret value that the server gives to your own page. The server makes an unpredictable token tied to the session. It requires this token on every request that changes data, in a header or a hidden form field. The attacker's site cannot read the token (because of the same-origin policy), so it cannot forge the request. There are two common types: the synchronizer token (the server stores it and compares) and the signed double-submit cookie (the token is sent both in a cookie and in a header, and the server checks that they match and that the signature is valid).
3. Check Origin (and Referer) on unsafe requests. Origin is a request header that tells the server which origin the request came from. Referer (the spelling is a historic typo) is a header with the URL of the page that made the request. An unsafe request is one that changes data, such as POST. Browsers set Origin on cross-site POST requests, and an attacker's page cannot fake it.
4. Fetch Metadata headers are headers that the browser adds to say how a request started. Sec-Fetch-Site says if it came from same-origin, same-site, cross-site or none. Reject requests that change data when it says cross-site.
5. Require a custom header (for example X-Requested-With) for JSON APIs. A page on another site cannot add a custom header unless the browser first sends a CORS preflight. CORS (Cross-Origin Resource Sharing) is the set of rules for when a site may call another origin. A preflight is an extra OPTIONS request that asks the other server for permission first. Your server refuses it, so the forged request is never sent.
6. Never change data on GET. Otherwise <img src="/delete?id=3"> would work, even with Lax.

Where SameSite=Lax falls short

• Same-site is not same-origin. a.example.com and b.example.com are the same site but different origins. They are sibling subdomains (two subdomains of the same parent domain). If an attacker finds XSS (or takes over a subdomain) on a sibling subdomain, they can send logged-in requests to your site with the cookie attached.
• GET requests with side effects still travel along when the user goes to your site from another site.
• Browser quirks: Chrome treats a cookie with no SameSite value as Lax, but for the first 2 minutes it still sends it on cross-site top-level POST requests. Firefox and Safari do not default to Lax. Set the value explicitly.
• Older browsers or browsers without support ignore it. Keep a CSRF token for sensitive actions.

Defending against XSS (whatever you store)

• Escape output by default. (Escaping means turning special characters, such as <, into harmless text so they show as text and do not run as code.) React escapes values you put in the page. The danger zones are dangerouslySetInnerHTML, innerHTML, href and src values from users (javascript: URLs), and markdown that was not sanitised (cleaned) (Lesson 07).
• Sanitise HTML that you must show. Sanitising means removing dangerous parts from HTML. Use a sanitiser with an allow-list (it keeps only tags you list as safe), such as DOMPurify (a popular sanitising library).
• Content Security Policy (CSP) is a response header that lists which sources of scripts and other files the page may use. It blocks inline and untrusted scripts, so injected code cannot run.
• Trusted Types is a browser feature that makes dangerous DOM places (like innerHTML) reject plain strings. They accept only values that your own safe code has approved.
• Check your dependencies and third-party scripts. A hacked script is XSS that you invited in.

Four patterns that hold up

Pattern 1: HttpOnly session cookie (the strong default for first-party apps)

Set-Cookie: __Host-sid=…; Path=/; Secure; HttpOnly; SameSite=Lax

• Token theft by XSS: blocked.
• CSRF: handled by SameSite plus a CSRF token or an Origin check on unsafe requests.
• Server rendering (building the HTML on the server) and API calls use the same login method. This is the easiest to understand.

Pattern 2: short-lived access token in memory plus HttpOnly refresh cookie (a SPA talking to an API)

A SPA (single-page app) is a site that loads once and then updates the page with JavaScript. An access token is a short-lived token that your API accepts. A refresh token is a long-lived token used only to get a new access token. (See Lesson 02.)

Page load ─▶ POST /auth/refresh (refresh cookie sent automatically, SameSite + CSRF check)          ◀─ { accessToken }  (kept in a JS variable, never persisted)API calls ─▶ Authorization: Bearer <accessToken>Reload    ─▶ the access token is gone, so call /auth/refresh again

• XSS cannot read the refresh cookie. The cookie is sent only to the auth endpoint (limit it with Path=/auth).
• The access token is not in storage. To steal it, the attacker needs code running at that moment. It also expires in minutes.
• The cost: one refresh call on every page load, and some extra work when many requests run at the same time.

Pattern 3: backend-for-frontend (BFF)

A backend-for-frontend (BFF) is a small server that you own, built for your frontend. It sits between the browser and the other APIs. The browser never sees an access token. It holds only a session cookie for your own backend. That backend keeps the tokens and calls other APIs for the user.

Browser ──session cookie──▶ Next.js server (BFF) ──Bearer token──▶ Resource APIs                               │                               └─ tokens stored server-side (encrypted session / Redis)

• XSS cannot steal tokens, because there are none in the browser.
• You handle refresh, scopes and logging in one place. OAuth (the standard way to let an app get access to an API for a user) has guidance for browser apps, and it recommends this pattern in most cases.
• In Next.js, route handlers (server code that answers HTTP requests) or server actions (server functions that the page can call) can act as the BFF. The other API stays private.

Pattern 4: bearer token in localStorage (and when it is defensible)

This is simple, has no CSRF problem, and works across domains. But any XSS can copy a credential that can be reused. It is acceptable only for low-risk apps. Even then, you need a short expiry, a strict CSP, as few third-party scripts as possible, and a risk that you accept on purpose. OWASP (the Open Worldwide Application Security Project) says session IDs and tokens should not be kept in localStorage or sessionStorage. In an interview, if you choose this pattern, say so and say what risk it leaves open.

Scenario: the SPA calls an API on another domain

The frontend is on app.example.com. The API is on api.otherdomain.com. What do you do?

1. Best: make it same-site. Put the API under your own domain (api.example.com), or pass it through your Next.js server (a rewrite or a BFF). Then cookies are first-party (set by the same site as the page) and SameSite=Lax works. A rewrite is a server rule that quietly forwards a path, such as /api/*, to another server.
2. If it must be cross-site, you need all of these. The cookie needs SameSite=None; Secure. The request needs credentials: "include" (a fetch option that tells the browser to send cookies on cross-origin requests). The API must send Access-Control-Allow-Origin: <exact origin> and Access-Control-Allow-Credentials: true (Lesson 04). You must add CSRF tokens. And you will have to deal with browsers that block third-party cookies (cookies set by a site other than the one in the address bar).
3. Or use bearer tokens with the memory-plus-refresh pattern or the BFF pattern. You accept the extra parts.

Common mistakes

1. "HttpOnly makes us safe from XSS." It only stops reading the cookie.
2. "We use JWT in a cookie, so no CSRF." A cookie is sent automatically, so CSRF applies no matter what is inside it.
3. Relying on SameSite=Lax alone while sibling subdomains host user content.
4. Endpoints that change data on GET.
5. Using CORS as CSRF protection. CORS limits who can read responses. A simple cross-site POST is still sent.
6. Putting the refresh token in localStorage. It lives the longest and is the most valuable secret.
7. Skipping cleanup at logout: not revoking the refresh token on the server.

Interview questions

Key takeaways

• XSS runs the attacker's code as you. CSRF makes your browser send requests you did not mean to send. They need different defences.
• localStorage tokens: no CSRF, but XSS can steal them. HttpOnly cookies: cannot be stolen, but they need CSRF defences, and XSS can still use the session.
• Strong defaults: HttpOnly session cookie (first-party), access token in memory + HttpOnly refresh cookie (SPA + API), or a BFF (sensitive apps).
• Make cross-domain APIs same-site when you can.
• Always use layers: escaping and sanitising, CSP, SameSite, CSRF tokens or Origin checks, and short token lifetimes.

What's next

Lesson 04: CORS Explained. Calls to APIs on other origins keep coming up. Next we explain exactly what the browser blocks, what triggers a preflight, and why your request "works in Postman" but fails in Chrome.