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. This is 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, and your progress syncs across the web and the CoddyKit app. The Frontend Academy course includes 4 lessons in total.
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=LaxSameSite=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 sessionDouble-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.
Learn HTML with an AI tutor — free
Write and run real code in your browser, get instant help from a 24/7 AI tutor, and pick up where you left off on the web or in the app.
- Courses
- 41
- Lessons
- 163
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. 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. The Frontend Academy course includes 4 lessons in total.
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, so you can start here or from the beginning and move at your own pace. This is lesson 2 of 4.
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
- XSS Prevention: Output Encoding CSP
- CSRF: SameSite Cookies and Tokens
- Content Security Policy: nonce and hash
- OAuth Flows from the Frontend