SameSite Cookie Attribute: Browser Support, Values, Defaults

What is the SameSite cookie attribute?

The SameSite cookie attribute is an HTTP Set-Cookie flag standardized by the IETF in RFC 6265bis. It tells the browser when to attach a cookie to outgoing requests, accepts the values Strict, Lax, and None, and lets servers block cross-site cookie sends to limit cross-site request forgery.

Which browsers does the SameSite cookie attribute support?

The SameSite cookie attribute works in every modern desktop and mobile browser. Chrome, Edge, Firefox, Opera, Safari, and Samsung Internet support all three values, while Internet Explorer 11 supports only Strict and Lax.

What are the SameSite cookie attribute values?

The SameSite cookie attribute accepts three values: Strict, Lax, and None. Each value sets a different rule for when the browser sends the cookie on cross-site requests.

• Strict: Sends the cookie only when the request is on the same registrable site. Top-level navigations from another origin do not include the cookie. Use Strict for high-trust cookies such as banking session tokens or password-reset flows.
• Lax: Sends the cookie on same-site requests and on top-level navigations from another site that use a safe HTTP method like GET. Cross-site fetch, XHR, iframe loads, and POST requests do not include the cookie. Lax is the modern default in Chrome, Edge, and Opera.
• None: Sends the cookie on every request, including cross-site fetches and iframe embeds. The cookie must also have the Secure attribute, so it only travels over HTTPS. Use None for third-party widgets, embedded payment frames, or single sign-on flows.

What is the default SameSite behavior in modern browsers?

Browsers fall into two camps for cookies that omit the SameSite attribute. Chromium-based browsers apply SameSite=Lax as the default, while Firefox and Safari leave the cookie with no SameSite enforcement and rely on their tracking-prevention layers to block obvious cross-site sends.

• Chrome, Edge, and Opera: Apply SameSite=Lax by default from Chrome 80, Edge 86, and Opera 67. A cookie sent without SameSite is treated as Lax for the first two minutes after creation under the Lax-allow-unsafe rule, then strict Lax behavior takes over.
• Firefox: Does not apply Lax by default. The about:config preference network.cookie.sameSite.laxByDefault can flip the behavior for testing, but the shipped default leaves cookies with no SameSite enforcement. Set the attribute explicitly on every cookie.
• Safari: Applies its own Intelligent Tracking Prevention rules instead of a Lax default, so cookies missing SameSite still travel cross-site under most conditions. Set the attribute to lock down behavior.
• Samsung Internet: Inherits the Chromium Lax-by-default behavior from Samsung Internet 13.0, which tracks Chromium 80.

How does SameSite mitigate CSRF attacks?

The SameSite cookie attribute is the simplest server-side CSRF defense in the modern web. It blocks the browser from sending session cookies on cross-site state-changing requests, which removes the foundation of most cross-site request forgery patterns.

• Strict blocks every cross-site send: Even a click on a link from another site does not include the cookie, so an attacker page cannot ride a victim's session at all.
• Lax blocks unsafe methods: A cross-site POST, PUT, or DELETE never carries the cookie, while top-level GET navigations still work. This balance covers the bulk of CSRF vectors without breaking inbound links from search engines and email.
• None reopens the door: Cookies marked SameSite=None ride every cross-site request, so they need a separate CSRF token or origin check to stay safe.
• Pair SameSite with a CSRF token: Even with Lax or Strict in place, OWASP recommends a synchronizer-token or double-submit-cookie pattern as a second layer for state-changing endpoints.
• Validate the Origin and Referer headers: Server-side checks on the Origin or Referer header catch cross-site requests on browsers that do not enforce SameSite, such as IE 11 with SameSite=None.

What are the known issues with the SameSite cookie attribute?

The SameSite cookie attribute is well supported, but it ships with a handful of real bugs and quirks that production teams hit. The biggest hitters are old Safari, the Chrome two-minute Lax window, and the SameSite=None Secure rule.

• Safari 12 treats SameSite=None as Strict: Safari 12 on macOS Mojave and iOS 12 has a known bug that drops SameSite=None cookies on cross-site requests. The fix shipped in Safari 13 on macOS Catalina and iOS 13.
• SameSite=None cookies require Secure: Chrome 80, Edge 86, and Firefox 69 reject any SameSite=None cookie that does not also set the Secure attribute, so HTTP origins cannot use third-party cookies.
• Two-minute Lax-allow-unsafe window: Chrome and Edge let a SameSite-less cookie ride a cross-site POST for up to two minutes after the cookie is set. This grace window can mask broken sign-in flows during testing.
• IE 11 ignores SameSite=None: Internet Explorer 11 treats unknown SameSite values as if the attribute were absent, so a None cookie on IE 11 falls back to default cookie behavior with no cross-site protection.
• Cross-subdomain pitfalls: SameSite is computed at the registrable domain level, also known as eTLD+1, so cookies set on a.example.com and called from b.example.com count as same-site even when teams treat the two hosts as separate apps.
• Lax does not protect cross-site GET endpoints: A state-changing GET request still receives the cookie under Lax. Any endpoint that mutates data on GET needs an explicit CSRF token, or the route must move to POST.

In my experience, the most painful regression is a sign-in iframe that fails only on Safari 12 because the SameSite=None cookie is silently dropped, and the team burns an afternoon hunting before noticing the version split between Safari 12 and Safari 13.

Citations

All SameSite cookie attribute version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - Set-Cookie header: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie
• MDN Web Docs - cookies.SameSiteStatus: developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/SameSiteStatus
• web.dev - SameSite cookies explained: web.dev/articles/samesite-cookies-explained
• Chromium - SameSite Updates FAQ: chromium.org/updates/same-site/faq
• Chrome for Developers - Get Ready for SameSite=None Secure: developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure
• WebKit - Tracking Prevention in WebKit: webkit.org/tracking-prevention
• OWASP - SameSite community page: owasp.org/www-community/SameSite
• IETF - HTTP State Management Mechanism (RFC 6265bis): datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis
• Mozilla Hacks - Changes to SameSite Cookie Behavior: hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior
• Microsoft Learn - Implement SameSite Cookie Attribute: learn.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update
• Microsoft Learn - Handle SameSite changes in Microsoft Edge: learn.microsoft.com/en-us/entra/identity-platform/howto-handle-samesite-cookie-changes-chrome-browser
• Wikipedia - HTTP cookie: en.wikipedia.org/wiki/HTTP_cookie