Does SameSite replace CSRF tokens?

It replaces most of the need. For extra-sensitive operations (money transfers, privilege changes), keep CSRF tokens as defense in depth.

I'm embedding my app in an iframe — what do I do?

Use `SameSite=None; Secure`. Without Secure, None is rejected by browsers.

Medium severity

How to fix cookies without a SameSite attribute

Your cookie is missing the `SameSite` attribute. SameSite determines whether the browser sends the cookie on cross-site requests. Without it, the cookie is sent on every request — which opens CSRF attacks on older browsers. Modern browsers default to `Lax`, but you should not rely on that. Set `SameSite=Lax` for most cookies, `SameSite=Strict` for sensitive operations (banking, admin), `SameSite=None; Secure` only when you truly need cross-site access.

Why it matters

SameSite is the simplest CSRF defense. Lax is good for most apps. Strict is safest but breaks external links. None is only for explicit cross-site auth (embedded widgets) and requires Secure.

How to check

01DevTools → Application → Cookies: check SameSite column.
02`Lax` is the default and usually fine. `None` without `Secure` is invalid.

Or let SafeToShip check it for you in 60 seconds:

How to fix it

Next.js

Set sameSite on every cookie. Lax is the default for most cases.

cookies().set({
  name: 'session',
  value: token,
  secure: true,
  httpOnly: true,
  sameSite: 'lax',  // or 'strict' for admin/finance
});

Generic

Add `SameSite=Lax` to every cookie.

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

AI prompt

Copy-paste into your AI tool

Paste this prompt into Cursor, Lovable, Bolt, v0, or Claude Code and it will walk through the fix for your specific codebase.

Audit every cookie my app sets. Add SameSite=Lax as the default. For cookies on admin or billing routes, use SameSite=Strict. If I have any cookies that need to work in embedded iframes or cross-site contexts, use SameSite=None; Secure and tell me exactly why that cookie needs cross-site access.

FAQ

Frequently asked questions

Does SameSite replace CSRF tokens?: It replaces most of the need. For extra-sensitive operations (money transfers, privilege changes), keep CSRF tokens as defense in depth.
I'm embedding my app in an iframe — what do I do?: Use `SameSite=None; Secure`. Without Secure, None is rejected by browsers.

Related fix guides

Fix these too

Cookie missing Secure flag

Cookies without the Secure flag can be sent over HTTP, leaking session tokens to anyone on the same network. Here is how to set it.

Cookie missing HttpOnly

HttpOnly stops JavaScript from reading a cookie, which is critical for session tokens. Here is when and how to set it.

CORS credentials misconfiguration

Setting both Allow-Origin: * and Allow-Credentials: true is a dangerous misconfiguration. Here is why browsers block it and how to fix it correctly.

Learn the concepts

Glossary

SameSite Cookie Attribute

SameSite controls whether the browser sends your cookie on cross-site requests. The main defense against CSRF.

Cross-Site Request Forgery

CSRF tricks a logged-in user into performing actions on your site without realizing. SameSite cookies are the modern defense.

Free tools

Check this yourself

Cookie audit

Check Secure, HttpOnly, and SameSite flags on every cookie.

Platform guides

Building on these platforms?

Next.js security

Next.js is the most popular React framework, but even experienced developers miss security headers and accidentally expose server files in production.

Vercel security

Vercel handles hosting and SSL, but your application code still needs security hardening. Missing CSP headers and exposed environment variables are the top issues.

Scan your site for this and 50+ other issues

Free scan. Results in 60 seconds. No account required.