What is the difference between SameSite Lax and SameSite None cookies?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• SameSite=Lax: sent on same - site requests and on cross - site top - level GET navigations; blocks cross - site sub - resource and POST requests; provides baseline CSRF defence; works over HTTP but should use Secure for safety.
• SameSite=None: sent on every request, including cross - site sub - resources and POSTs; must include the Secure attribute or browsers will drop it; used only when a cookie must be accessed by a different origin.
• Modern browsers default to SameSite=Lax when the attribute is omitted.
• Choosing the wrong value can break third - party integrations or expose you to CSRF attacks.

What does SameSite=Lax actually do?

SameSite=Lax allows the cookie to travel on same - site requests and on cross - site top - level navigations that use a safe HTTP method such as GET. It does not send the cookie on cross - site sub - resource requests (images, iframes, fetch/AJAX) or on cross - site POST/PUT/DELETE forms. This behavior stops the most common CSRF vectors while still letting a user click a link from another site and stay logged in.

What does SameSite=None actually do?

SameSite=None disables SameSite protection entirely. The cookie is included on all requests, both same - site and cross - site, including sub - resources, POSTs, iframes, and fetches. Because the cookie is exposed everywhere, browsers require the Secure attribute; a cookie with SameSite=None that is not Secure is silently rejected.

Why does the Secure flag matter for SameSite=None?

The Secure flag forces the cookie to be sent only over HTTPS. Without it, a SameSite=None cookie could be leaked over an insecure connection, undermining confidentiality. Browsers enforce this rule: any SameSite=None cookie lacking Secure is dropped, protecting users from accidental exposure.

Default behavior when the attribute is omitted

Since Chrome 80 and other modern browsers, omitting the SameSite attribute is treated as SameSite=Lax. This means you get baseline CSRF protection without any configuration, but you also lose the ability to send cookies cross - site unless you explicitly set SameSite=None; Secure.

Typical use - cases for SameSite=Lax

• Standard session cookies that only need to survive a user clicking a link into the site.
• Cookies that should not be sent on cross - site POST forms or embedded resources.
• Scenarios where you want the simplest CSRF defence without extra code.

Typical use - cases for SameSite=None

• Third - party widgets, ads, or analytics pixels that need to read a cookie from a different origin.
• OAuth / OpenID Connect callback flows that involve a cross - site POST.
• Any integration where a cookie must be available to another domain (e.g., a CDN that sets authentication state).

Example Set - Cookie headers

Set-Cookie: sessionId=abc123; SameSite=Lax; Secure; HttpOnly
Set-Cookie: widgetToken=xyz789; SameSite=None; Secure; HttpOnly

The first cookie will be omitted on cross - site POSTs or image requests; the second will travel on every request but only over HTTPS.

How to choose the right setting

1. Ask yourself if the cookie ever needs to be read by another origin. If no, use SameSite=Lax (or omit the attribute).
2. If cross - origin access is required, set SameSite=None; Secure. Verify that the site is always served over HTTPS.
3. Add HttpOnly and Secure where possible for defense - in - depth, regardless of SameSite value.
4. Test in multiple browsers, especially older ones that may interpret None as Strict and break functionality.

Common pitfalls

• Forgetting the Secure flag for SameSite=None results in the cookie being dropped silently.
• Assuming SameSite=None works over HTTP; it does not.
• Relying on the default Lax when a third - party integration actually needs cross - site POSTs; this will cause authentication failures.

Summary

SameSite=Lax offers a safe default that blocks most cross - site request forgery attacks while still allowing normal navigation. SameSite=None removes that protection and should only be used when a cookie must be shared across origins, and it must always be paired with Secure. Understanding the trade - off helps you protect users without breaking legitimate cross - origin workflows.