Choosing a SameSite Cookie Policy in Chrome: Lax, Strict, or None

The decision you actually have to make

Since Chrome 80, any cookie set without an explicit SameSite attribute is treated as SameSite=Lax. This default behavior prevents cookies from being sent on cross-site POST requests, which silently breaks integrations like payment return flows, SSO callbacks, and embedded widgets. If you manage a site that sets cookies, you must choose a policy based on how the cookie is used, rather than applying a universal security setting.

The core constraint is that Chrome, not your server, decides whether a cookie travels with a cross-site request. Your only mechanism for control is the SameSite attribute in the Set-Cookie header.

Comparing SameSite Options

Critical Requirement: Chrome rejects SameSite=None cookies that lack the Secure attribute. If Secure is missing, the browser drops the cookie entirely, and a warning will appear in DevTools.

Engineering Trade-offs

Lax is the balanced default. It mitigates the primary Cross-Site Request Forgery (CSRF) vector—where a malicious site submits a POST form to your server using the user's session—while still allowing users to arrive at your site logged in via a link from an email or search engine.

Strict impacts user experience. Because cookies are not sent on any cross-site navigation, a user clicking a link to your app from an external site will appear unauthenticated on the initial page load. This is often unacceptable for consumer-facing applications.

None; Secure is an opt-in to risk. Setting this restores the unrestricted behavior seen before Chrome 80. Because your endpoints will once again receive cookies on forged cross-site requests, you must implement independent CSRF defenses, such as anti-forgery tokens validated server-side or strict Origin and Referer header verification.

Implementation and Configuration

The attribute must be set on the Set-Cookie header emitted by your application server. For a standard session cookie that should remain within your site context:

Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

For a cookie intended for use inside a third-party iframe (e.g., an embedded dashboard):

Set-Cookie: widget_session=xyz789; Path=/; HttpOnly; Secure; SameSite=None

In a Node.js Express environment, this is configured via the cookie options object: res.cookie('session', token, { httpOnly: true, secure: true, sameSite: 'lax' }).

Validating Browser Behavior

Do not rely on framework defaults; verify the actual state in the browser.

Manual DevTools Inspection

Open Chrome DevTools > Application > Storage > Cookies. Select your origin and inspect the SameSite column. If a cookie intended as None appears as Lax, it usually indicates the Secure attribute was missing, causing Chrome to ignore the None setting.

Header Verification via curl

Run the following command from a terminal to verify the raw header emitted by your server:

curl -sI https://your-site.example/login | grep -i set-cookie

This check confirms what the server sends, but not how Chrome interprets it. The DevTools check remains the authoritative source for browser behavior.

Behavioral Testing

To verify SameSite=None, create a minimal HTML page on a different origin (e.g., a different localhost port) with a form that POSTs to your endpoint. Load this page in Chrome and check the Network panel to confirm the Cookie header is attached to the request. If it is missing, the browser is blocking the cookie.

Limitations

Cookie behavior is version-dependent. While these rules apply to Chrome 80+, different browser engines (WebKit/Safari, Gecko/Firefox) have distinct timelines and policies regarding third-party cookies. Furthermore, Chrome's Privacy Sandbox initiative may introduce further restrictions on third-party cookies regardless of the SameSite attribute. Always test against the specific Chrome versions your users utilize.