How do I fix a cookie that is missing the SameSite attribute?

A session cookie with no SameSite attribute leaves the browser with no rule about sending it on cross-site requests, which weakens your defences against cross-site request forgery. A cookie missing the SameSite attribute is easy to overlook because some browsers now default to Lax on their own — but relying on that default is a mistake. This page explains what SameSite does and how to set SameSite=Strict, Lax, or None in Nginx, Apache, Express, and Next.js.

Why this matters

SameSite controls whether the browser attaches a cookie to a request whose origin differs from the site the cookie belongs to (MDN Set-Cookie). Strict sends the cookie only on same-site requests; Lax sends it on same-site requests plus top-level navigations using safe methods; None removes the restriction entirely and requires the Secure attribute to be present. The danger of an absent attribute is unpredictability: some browsers treat missing SameSite as Lax by default, so behaviour can vary across engines and versions, and you should not depend on that default. OWASP's Session Management Cheat Sheet advises setting SameSite as a defence-in-depth control, and its CSRF Prevention Cheat Sheet is clear that SameSite is not a complete replacement for a CSRF token — it reduces the attack surface but does not close every path, especially on older or unusual clients. The strongest practical setting for a session cookie is Lax, which preserves normal navigation while blocking the classic cross-site form POST, and Strict when the cookie is only ever needed after the user is already on your site.

How to fix it

Choose the setting deliberately rather than letting the browser guess. Use Lax as the default for session cookies, use Strict for cookies that are never needed on an incoming navigation, and use None only when a cookie genuinely must travel on cross-site requests, such as an embedded or OAuth flow — and then always pair it with Secure. Nginx's proxy_cookie_flags accepts samesite=strict, samesite=lax, and samesite=none, and Express and Next.js both take a sameSite value in their cookie options. The snippets below are from each vendor's documentation.

location / {
    proxy_pass http://app:3000;
    proxy_cookie_flags ~ secure httponly samesite=lax;
}

res.cookie('session', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'lax'
});

'use server'
import { cookies } from 'next/headers'

export async function setSession(token) {
  const cookieStore = await cookies()
  cookieStore.set('session', token, {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    path: '/'
  })
}

Apache's mod_headers has no dedicated cookie-flag directive, so the documented edit action is used to search-and-replace the Set-Cookie value. Cloudflare Workers lets you append a full Set-Cookie response header with the attribute included.

Header edit Set-Cookie ^(.*)$ "$1; SameSite=Lax"

const headers = new Headers();
headers.append("Set-Cookie", "session=" + token + "; Path=/; HttpOnly; Secure; SameSite=Lax");
return new Response(body, { headers });

How to verify the fix

Request the endpoint that sets the cookie and read the raw response header. SameSite should appear with an explicit value. In a browser, open DevTools, go to Application, then Cookies, and read the SameSite column for the session cookie.

curl -sI https://example.com/login | grep -i "set-cookie"

Related issues