Frontend Academy · Lesson

CSRF: SameSite Cookies and Tokens

Understand how Cross-Site Request Forgery exploits cookies, use SameSite=Strict/Lax to prevent it, and add synchroniser tokens for extra protection.

CSRF: SameSite Cookies and Tokens is a free Frontend Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Frontend Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Is CSRF?

Cross-Site Request Forgery: an attacker tricks an authenticated user's browser into sending a request to your site. The browser attaches the user's cookies — the server thinks it's a legitimate request from the user.

Classic CSRF Attack

User is logged into bank.com. They visit evil.com. evil.com submits a hidden form to bank.com/transfer with attacker's account number. Browser sends bank.com's session cookie automatically. Server transfers money.

The Trust Problem

CSRF works because browsers automatically include cookies on cross-origin requests. The server can't tell the request came from a malicious site without extra protection.

SameSite Cookies — The Modern Fix

The SameSite cookie attribute controls when cookies are sent on cross-origin requests. Strict: never sent cross-origin. Lax (default in Chrome): sent on top-level GET navigation only. None: always sent (must also be Secure).

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax

SameSite=Lax Default

Chrome defaults all cookies to Lax if no SameSite is specified. This blocks most CSRF — but you should be explicit anyway.

SameSite=Strict for Maximum Security

Use Strict for the most sensitive cookies (admin sessions, bank transactions). Downside: the user appears logged out when arriving via a link from another site.

CSRF Tokens (Synchroniser Pattern)

For older browser support or extra safety, use CSRF tokens. The server generates a random token, embeds it in the page, and requires it on every state-changing request.

// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">

// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': token },
  body: JSON.stringify({ amount: 100 })
});

// Server verifies the X-CSRF-Token header matches the user's session

Double-Submit Cookie

Server sets a CSRF cookie (non-HttpOnly so JS can read it). Client reads it and sends the value in a header. Server checks the cookie matches the header. An attacker can't read the cookie cross-origin, so they can't replicate the header.

Why It Works

The attacker's evil.com cannot read cookies from bank.com (Same-Origin Policy). So they cannot set the X-CSRF-Token header. The request fails the token check on the server.

CSRF in SPAs Using Bearer Tokens

If you authenticate with Authorization: Bearer <jwt> stored in memory (not a cookie), CSRF doesn't apply — browsers don't auto-send headers. Trade-off: more vulnerable to XSS (since JS-accessible tokens can be stolen).

Custom Header Trick

For APIs that only accept JSON with a custom header (e.g. X-Requested-With), browsers send a preflight OPTIONS request — and won't include cookies on the preflight. Effectively blocks simple form-based CSRF.

Idempotent vs Mutating Endpoints

CSRF mostly affects state-changing requests (POST, PUT, DELETE). GET endpoints should be idempotent — performing no side effects — so a forged GET can't do harm.

Quick Check

Which SameSite cookie value prevents cookies from being sent on most cross-site requests by default in modern browsers?

Recap: CSRF Prevention

Set SameSite=Lax (or Strict) on session cookies — blocks most CSRF. Add HttpOnly + Secure. Use CSRF tokens (synchroniser or double-submit cookie) for extra protection. Bearer tokens in headers avoid CSRF but increase XSS risk. Custom header trick forces preflight. Make GETs idempotent.

Frequently asked questions

Is the “CSRF: SameSite Cookies and Tokens” lesson free?

Yes — the full text of “CSRF: SameSite Cookies and Tokens” is free to read here on the web, and the Frontend Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Frontend Academy course, upgrade to CoddyKit PRO.

What will I learn in “CSRF: SameSite Cookies and Tokens”?

Understand how Cross-Site Request Forgery exploits cookies, use SameSite=Strict/Lax to prevent it, and add synchroniser tokens for extra protection. You practise Frontend Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Frontend Academy?

No prior experience is required. Frontend Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “CSRF: SameSite Cookies and Tokens” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Frontend Academy lesson?

Yes. Every Frontend Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Frontend Academy