Default behavior cookie flags in 2021

Question

I'm under the understanding that in 2019, Chrome and Firefox both planned to move to SameSite=lax default for all unspecified cookies. In addition, recently, Chrome decided to set defaults based on other information such as the 'secure' flag, and whether or not communications were sent over HTTPS. My understanding is that Chrome has since backflipped on this,

Can SameSite be relied on as an effective control against CSRF for HTTP POST requests? If a cookie does not have no SameSite directives and the website have no other anti-CSRF, should it be considered a vulnerability?

Are there any other impacts relevant to samesite in modern, and historic browsers? Does IE11 support SameSite? What about IE11 on Windows 7 (noting that for some reason, Microsoft decided to not implement/disable CSP on Win7/IE11), What about when using unencrypted HTTP or when the secure flag is not set (I ask because other Chrome cookie behavior seems dependent on this facto)? Is there any other unexpected behaviors of samesite?

Answer 1

So far as I know, the current (as of Jan 2023) default behavior is that all Blink and Gecko-based browsers (mostly meaning based on Chrome/Opera/Edge and Firefox, respectively) - but not Safari or other Webkit-based browsers - implement SameSite=Lax by default, only allow SameSite=None for Secure cookies, and also support cookie name security prefixes, but don't otherwise do anything novel or interesting with cookies unless the server or script says to.

Modern Safari (and other Webkit-based browsers) and also slightly outdated browser engines (as found in pre-Blink Edge or IE11 on Windows 10 from fall 2017 or newer, or similarly-old versions of the above browsers) will support SameSite but default to None instead of Lax, and lack the restriction of allowing None only on Secure cookies.

IE and pre-Blink Edge never got prefix support on any version. Blink and Gecko got prefix support in Mar 2016 and Nov 2016, respectively, slightly before Blink got SameSite (May 2016) and long before Gecko did (May 2018). Safari/Webkit in particular had no SameSite support on operating systems before OS 10.14 (Mohave) and also had a bug in handling any SameSite flags other than Lax and Strict (they'd act as though you'd specified Strict if any other flag was specified, even None; to actually get None you had to not set SameSite at all) until MacOS 10.15 (Catalina) and iOS 13. Safari added prefix support in 16.2, released in Dec 2022.

Some mobile browsers were slower than their desktop equivalents to add these features. In general, though, if they're based on the same engine as a desktop browser, they'll have the same cookie handling features. Note that, due to Apple's restrictions on code execution in third-party apps, all iOS browsers are Webkit based even if the desktop version of that browser uses Blink or Gecko.

No version of Internet Explorer/pre-Blink Edge for older Windows (pre-Fall-2017 update Win10, or any pre-Win10), nor any version of any browser from before Mar 2016, supports either SameSite or cookie prefixes at all.

This information has mostly been sourced from https://caniuse.com/?search=SameSite and https://caniuse.com/?search=cookie%20prefix, with specific details verified on MDN and other sites.

---

Relying on SameSite for CSRF protection is rather fraught, in a way that numerous answers on this site have already gone into. Some such questions, linked automatically in the "Related Questions" sidebar, are Current status of SameSite cookie and For SameSite cookie with subdomains what are considered the same site?. Suffice it to say that even if your users run modern browsers, you're arguably better off continuing to use existing CSRF protections (including things like not allowing "simple" requests for state-changing actions - require a custom header or a Content-Type like application/json - and not allowing CORS preflights from untrusted origins) rather rely on SameSite. Explicitly setting SameSite=Lax does work cor CSRF protection if your users aren't on browsers more than a few years old, AND you have no untrusted or under-secured subdomains of your primary (public suffix plus one) domain regardless of what port or protocol they're on.

Answer 2

No, the SameSite=Lax attribute-value (or the absence of the SameSite attribute) is not enough to protect against CSRF because browsers are required to send Lax cookies across origins in "top-level navigation", such as submitting HTML forms or clicking links or following client-side redirects.

4.1.1. "Strict" and "Lax" enforcement

[...] developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a "safe" (in the [RFC7231] sense) HTTP method.

https://datatracker.ietf.org/doc/html/draft-west-first-party-cookies-07#section-4.1.1

However, if the application uses non-navigational authentication tokens (i.e. not cookies, not platform authentication, but "Authorization: Bearer" or other request header tokens), it is protected against unauthorized writes. Another way to protect is for the server to check the incoming "Origin" request header against a white list of authorized origins, also allowing the absence of the header, and reject unauthorized requests. This will also clarify the protection against accidental CORS misconfiguration, so that XHR read attempts will be rejected.