CSRF protection in Next.js — when you need it, when you don't

What it is

If your app authenticates via cookies and a state-changing action can be triggered by a GET or by a simple-content-type POST from a different origin, you are vulnerable. CSRF tokens verify the request originated from your own form.

Vulnerable example

// Vulnerable: any origin can POST a form that changes user email.
export async function POST(req: Request) {
  const form = await req.formData();
  const email = form.get("email") as string;
  const session = await getSession(); // cookie-based
  await prisma.user.update({ where: { id: session.userId }, data: { email } });
  return Response.redirect("/settings");
}

Fixed example

// Fixed: verify a double-submit CSRF token
import { cookies, headers } from "next/headers";

export async function POST(req: Request) {
  const form = await req.formData();
  const fromForm = form.get("csrf_token");
  const fromCookie = (await cookies()).get("csrf_token")?.value;
  if (!fromForm || fromForm !== fromCookie) {
    return new Response("csrf", { status: 403 });
  }
  // ...continue
}

How Securie catches it

// Fixed: verify a double-submit CSRF token
import { cookies, headers } from "next/headers";

export async function POST(req: Request) {
  const form = await req.formData();
  const fromForm = form.get("csrf_token");
  const fromCookie = (await cookies()).get("csrf_token")?.value;
  if (!fromForm || fromForm !== fromCookie) {
    return new Response("csrf", { status: 403 });
  }
  // ...continue
}

Checklist

• State-changing routes (POST/PUT/PATCH/DELETE) have CSRF defense if auth is cookie-based
• Header-based auth (Bearer token in Authorization) does not need CSRF tokens for same-reason protection
• SameSite=lax is the baseline; pair with an origin/referer check for sensitive routes
• GET requests never change state
• Form actions in Server Components use a signed token

FAQ

Related guides