SameSite default limits cross‑site POSTs in Chrome 80+

Question

SameSite default limits cross‑site POSTs in Chrome 80+
Chrome 80 and newer treat cookies without an explicit SameSite attribute as Lax. This default prevents the cookie from being sent on cross‑site POST requests, a behavior that often succeeds locally on localhost but fails on production HTTPS domains.
The policy is documented in Chrome’s SameSite cookie specification, but an unresolved decision remains: should SameSite=None be allowed when the Secure flag is omitted? Allowing it would enable cross‑site cookie usage locally but could expose production sites to security risks.
Because the default can change in future releases and can be overridden by enterprise policy, developers face uncertainty when relying on the current behavior.
Unresolved questions

What is the current Chrome policy for SameSite=None without the Secure flag in version 80+?
Will upcoming Chrome releases modify the default SameSite value for unspecified cookies?

Tasadduq Burney · Answer

Answer
Chrome 80 and newer defaults cookies with no SameSite attribute to SameSite=Lax. Lax cookies are not sent on cross-site POST requests. That is the confirmed behavior causing the production failure you describe.
For a cross-site POST to carry a cookie, the cookie must be set with SameSite=None; Secure. Chrome 80+ rejects a SameSite=None cookie that is missing the Secure flag. The cookie is not stored and is not sent. This rejection is confirmed in public Chrome releases as of 2026.
Confirmed facts vs likely explanation
Confirmed:

Unspecified SameSite defaults to Lax in Chrome 80+.
SameSite=None without Secure is rejected by Chrome; it will not be set or sent.
With SameSite=None; Secure present, the cookie is sent on cross-site POSTs to HTTPS origins.

Likely explanation for localhost success: http://localhost is treated as a secure context for the Secure flag requirement in development. A SameSite=None cookie without Secure may appear to work on localhost but will be rejected on a production HTTPS domain. This is why the behavior differs between local and production.
What to do for this case

Set the cookie with explicit attributes: SameSite=None; Secure; Path=/ . Do not rely on the default.
Ensure the site is served over HTTPS in production. Secure is mandatory for SameSite=None.
Verify in Chrome DevTools Application > Cookies that the cookie shows SameSite=None and Secure, and status is not rejected.
Perform a cross-site POST from the originating site and inspect the request headers to confirm the Cookie header is present.

Enterprise policy can override SameSite defaults in managed deployments. If you are testing in a managed browser, behavior may differ from standard Chrome.
Future default changes: No publicly announced change to the unspecified SameSite default has been published for upcoming Chrome releases as of 2026-10-15. The policy is subject to revision, so avoid relying on unspecified behavior long term.
One diagnostic detail that changes the recommendation: Is the cookie being set by your server with Secure=true in production, and are you testing on a non-localhost HTTPS origin? If Secure is missing in production, the fix is to add it; if you are still on http, the issue is expected.

SameSite default limits cross‑site POSTs in Chrome 80+

SameSite default limits cross‑site POSTs in Chrome 80+

Unresolved questions

1 answer

Answer

Confirmed facts vs likely explanation

What to do for this case

Your perspective belongs here.

0 question comments