CSRF, cookies & tokens

Protect sessions and requests

Authentication is not one feature. It is a chain of browser behavior, server checks, token lifetimes, and user redirects. The earlier lessons on cookies, Web Storage, fetch, requests in depth, and CORS taught the pieces. This lesson shows how those pieces fail or protect real sessions.

An origin is scheme, host, and port. A site is based on the registrable domain, such as example.co.uk, and modern cookie rules are usually schemeful: https://example.com and http://example.com are not the same site. Real browsers use the Public Suffix List; the helper below uses a tiny hardcoded sample for teaching.

1const publicSuffixSample = ["co.uk", "github.io", "com", "org", "net", "dev"];2 3function registrableDomain(hostname) {4  const labels = hostname.toLowerCase().split(".");5  const suffix = publicSuffixSample6    .sort((a, b) => b.split(".").length - a.split(".").length)7    .find((item) => hostname === item || hostname.endsWith("." + item));8  if (!suffix) return labels.slice(-2).join(".");9  const suffixLength = suffix.split(".").length;10  return labels.slice(labels.length - suffixLength - 1).join(".");11}12 13function site(url) {14  const parsed = new URL(url);15  return parsed.protocol + "//" + registrableDomain(parsed.hostname);16}17 18function sameOrigin(a, b) {19  return new URL(a).origin === new URL(b).origin;20}21 22function sameSite(a, b) {23  return site(a) === site(b);24}25 26const page = "https://app.example.co.uk/settings";27const api = "https://api.example.co.uk/profile";28console.log(sameOrigin(page, api));29console.log(sameSite(page, api));30console.log(site(api));

That distinction matters for sessions. A cookie-based session stores a random session ID in a cookie, often HttpOnly; Secure; SameSite=Lax. The browser sends the cookie when the cookie rules match, and the server looks up the session. A bearer-token API instead expects a header such as Authorization: Bearer .... Whoever holds that token can present it, so storage and lifetime matter.

Cross-site request forgery depends on one browser feature: matching cookies can be attached to a request even when another site caused the request. A classic example is an auto-submitting form on an attacker-controlled page that posts to a signed-in banking site. The malicious page cannot read the banking response, but the state-changing request might still arrive with the victim's session cookie.

• At risk: state-changing requests authenticated by cookies.
• Lower risk: read-only GET requests. GET must be safe because links, preloads, crawlers, and images can trigger it.
• Different problem: bearer tokens in JavaScript storage are not attached automatically, but XSS can steal or use them.

1function shouldAttachCookie(cookie, request) {2  const sameSite = cookie.sameSite ?? "Lax";3  const crossSite = request.topLevelSite !== request.requestSite;4  const safeTopLevelGet = request.topLevelNavigation && request.method === "GET";5 6  if (sameSite === "None" && !cookie.secure) return false;7  if (!crossSite) return true;8  if (sameSite === "Strict") return false;9  if (sameSite === "Lax") return safeTopLevelGet;10  return true;11}12 13const request = {Run14  topLevelSite: "https://attacker.example",15  requestSite: "https://bank.example",16  method: "POST",17  topLevelNavigation: true,18};19 20console.log(shouldAttachCookie({ sameSite: "Lax", secure: true }, request));21console.log(shouldAttachCookie({ sameSite: "None", secure: true }, request));

Current major browsers treat a missing SameSite as Lax-like by default, and SameSite=None requires Secure. Chrome once had a temporary “Lax+POST” compatibility grace period for recently set cookies. Do not design around that historical exception: set the attribute you mean and protect writes on the server.

SameSite is a strong layer, not the whole design. A synchronizer token stores an unpredictable value in the server-side session and renders it into the legitimate page. A double-submit token puts a value in a readable cookie and requires the same value in a form field or header, often signed by the server. Either way, a different site should not be able to read the token and echo it on a forged state-changing request.

1// Server-side sketch, not browser JavaScript.2if (request.method !== "GET") {3  assertSameOrigin(request.headers.get("Origin"));4  assertEquals(request.cookies.csrf, request.body.csrfToken);5}6performStateChange();

Production servers often combine token checks with Origin or Referer validation, Sec-Fetch-Site checks, and method discipline. Custom headers such as X-CSRF-Token also make a cross-origin script request non-simple, so browsers send a preflight before the real request. Treat that as friction, not authorization: the server still validates the token, session, method, and user permission.

1document.cookie = "cf_visible_token=reader; Max-Age=60; Path=/; SameSite=Lax";2const visible = document.cookie.includes("cf_visible_token=reader");3console.log(visible);4document.cookie = "cf_visible_token=; Max-Age=0; Path=/";

1Set-Cookie: __Host-session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax2Set-Cookie: csrf=public-token; Path=/; Secure; SameSite=Lax

Browser storage is not a vault. The Web Storage lesson showed that localStorage and sessionStorage are readable by any script running on the page. If an XSS bug runs attacker code, that code can copy those tokens or call APIs before you notice.

1const localStorage = new Map();2localStorage.set("access_token", "eyJhbGciOiJub25l" + "." + "eyJzdWIiOiIxMjMifQ" + ".");3 4function injectedScript(storage) {5  return storage.get("access_token");6}7 8console.log(injectedScript(localStorage).slice(0, 6));9console.log("XSS can read JS storage");

There is no silver bullet. Short access-token lifetimes reduce damage. Refresh-token rotation makes each refresh token single-use and lets the server detect replay. In-memory tokens reduce persistence, but a live XSS can still act as the user. A backend-for-frontend keeps OAuth tokens server-side and gives the browser an HttpOnly session cookie, but then you are back to cookie CSRF defenses.

CORS answers a narrow browser question: may this page read that cross-origin response? It does not decide whether the server should perform the action. Simple requests, including form-like POST requests, can still reach the server. Non-browser clients such as curl do not enforce CORS. Your API must authenticate, authorize, and validate every request.

1function decideCors(request, response) {2  const simpleMethod = ["GET", "HEAD", "POST"].includes(request.method);3  const simpleContentType = ["text/plain", "multipart/form-data", "application/x-www-form-urlencoded"]4    .includes(request.headers["Content-Type"]);5  const simple = simpleMethod && simpleContentType;6 7  const actualRequestSent = simple || response["Access-Control-Allow-Methods"]?.includes(request.method);8  const readable = response["Access-Control-Allow-Origin"] === request.origin &&9    (request.credentials !== "include" || response["Access-Control-Allow-Credentials"] === "true");10 11  return { simple, actualRequestSent, readable };12}13 14const request = {Run15  origin: "https://app.example",16  method: "POST",17  headers: { "Content-Type": "text/plain" },18  credentials: "include",19};20const response = {};21const result = decideCors(request, response);22console.log(result.simple);23console.log(result.actualRequestSent);24console.log(result.readable);

1function decideCors(request, response) {2  const simpleMethod = ["GET", "HEAD", "POST"].includes(request.method);3  const simpleContentType = ["text/plain", "multipart/form-data", "application/x-www-form-urlencoded"]4    .includes(request.headers["Content-Type"]);5  const simple = simpleMethod && simpleContentType;6 7  const actualRequestSent = simple || response["Access-Control-Allow-Methods"]?.includes(request.method);8  const readable = response["Access-Control-Allow-Origin"] === request.origin &&9    (request.credentials !== "include" || response["Access-Control-Allow-Credentials"] === "true");10 11  return { simple, actualRequestSent, readable };12}13 14const request = {15  origin: "https://app.example",16  method: "POST",17  headers: { "Content-Type": "text/plain" },18  credentials: "include",19};20const response = {};21const result = decideCors(request, response);22console.log(result.simple);23console.log(result.actualRequestSent);24console.log(result.readable);

Credentialed browser reads are stricter: Access-Control-Allow-Origin: * cannot be combined with credentials. The server must echo the exact allowed origin and send Access-Control-Allow-Credentials: true. If it dynamically echoes origins, it should also send Vary: Origin so shared caches do not mix responses.

OAuth separates the person, the application, the login/token issuer, and the API. A browser SPA is a public client because it cannot keep a client secret. The modern pattern is authorization code flow with PKCE: the app creates a high-entropy code_verifier, sends a derived code_challenge during the redirect, then proves the verifier when exchanging the authorization code.

Resource owner: the person signing in
Client: the JavaScript app or its backend-for-frontend
Authorization server: issues codes and tokens
Resource server: the API that accepts access tokens
Flow for SPAs: authorization code + PKCE + state, not implicit

1function base64url(bytes) {2  let binary = "";3  for (const byte of bytes) binary += String.fromCharCode(byte);4  return btoa(binary).split("+").join("-").split("/").join("_").replace(/=+$/g, "");5}6 7async function pkceChallengeFromVerifier(verifier) {8  const bytes = new TextEncoder().encode(verifier);9  const digest = await crypto.subtle.digest("SHA-256", bytes);10  return base64url(new Uint8Array(digest));11}12 13(async () => {14  const verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk";15  const challenge = await pkceChallengeFromVerifier(verifier);16  console.log(challenge);17  console.log(challenge === "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM");18})();

The state parameter is separate from PKCE. It binds the authorization response to the browser flow that started it, protecting the redirect from CSRF-style mix-ups. Access tokens go to resource servers. Refresh tokens get new access tokens and should be rotated or sender-bound. ID tokens are OpenID Connect identity assertions for the client, not API authorization tokens. OAuth security guidance deprecates the implicit flow; OAuth 2.1 drafts remove it in favor of authorization code with PKCE.

Many OAuth and OpenID Connect deployments use JWTs. A JWT has base64url-encoded parts separated by dots: header, payload, and signature. JavaScript can decode the first two parts to inspect JSON, using the same base64url ideas from Text encoding. That is not verification. Verification checks the signature, issuer, audience, expiration, and other claims with trusted keys.

1function base64UrlToText(part) {2  const base64 = part.replace(/-/g, "+").replace(/_/g, "/")3    .padEnd(Math.ceil(part.length / 4) * 4, "=");4  const bytes = Uint8Array.from(atob(base64), (char) => char.charCodeAt(0));5  return new TextDecoder().decode(bytes);6}7 8const token = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoicmVhZGVyIn0.signature";9const [headerPart, payloadPart] = token.split(".");10const header = JSON.parse(base64UrlToText(headerPart));11const payload = JSON.parse(base64UrlToText(payloadPart));12 13console.log(header.alg);14console.log(payload.sub);15console.log("read, not verified");

Common misconceptions

• “CORS stops CSRF.” It does not. CORS controls browser reads, while CSRF is about forged writes.
• “SameSite means I do not need tokens.” SameSite is a layer. Sensitive writes still deserve server checks.
• “HttpOnly cookies are always safer.” They hide values from JavaScript, but they still ride with requests.
• “localStorage is safe because it is same-origin.” XSS runs in that origin and can read it.
• “JWTs are secure because they look encoded.” Base64url is reversible. Trust comes from verification and claims.
• “PKCE replaces the state parameter.” PKCE protects code exchange; state protects the redirect flow.

Key takeaways

• CSRF targets state-changing, cookie-authenticated requests because browsers attach matching cookies automatically.
• Use safe GETs, explicit SameSite cookies, CSRF tokens, Origin/Sec-Fetch-Site checks, and authorization on every write.
• Web Storage is script-readable; an XSS bug can steal localStorage or sessionStorage tokens.
• HttpOnly cookies reduce JavaScript token theft but require CSRF defenses.
• CORS controls whether browser JavaScript can read a response; it is not server-side access control.
• SPAs should use authorization code with PKCE and state; decoding a JWT is not verifying it.

Final definition: secure browser authentication is a layered design: choose how credentials travel, prevent forged writes, keep tokens out of script-readable storage when possible, and verify every token or session server-side.

Up next: prototype pollution and unsafe object merges.