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?


The CSRF attack scenario relies on the victim browsers which are almost always latest greatest. Having an outdated browser (even a Firefox of few major versions back) presents a greater risk than CSRF due to chances of breaching the browser itself.

The SameSite attribute (and the transition to the Lax value from None by default) guards applications whose UI is hosted by the same host with API or by a sub-host of API. Such same-site UI hosting turns friendly to own API cookies. CSRF attacks rely on accidental surfing foreign (malicious or hacked) origins. Browsers will ignore SameSite=Lax and strict cookies when these origins send malicious requests to API. (Surfing through a hacked sub-host of API will send the API cookies, so this less likely chance needs weighing).

The Lax or Strict value of the attribute (or its default Lax value) turns prohibitive for previously normal operation of applications where API is hosted by a sub-host of UI or by a sibling host of UI or by an unrelated host. These disperse applications turn to using tokens. Tokens are not sent by the browser's platform authentication in case of a CSRF attack.

I read that only HTTP GET requests were supposed to carry Lax cookies across sites (if resulting from a click, I guess). But the browser vendors permitted fresh Lax cookies to be sent with POST requests for some transitional period.

Finally, from my other reading, I suspect that Microsoft web apps and OpenID authentication implementations heavily depend on passing cookies across sites. That is, they fail in newer browsers.

  • 1
    Site != origin. See web.dev/same-site-same-origin
    – jub0bs
    May 2 at 16:35
  • Thanks @jub0bs, I see that sub-hosts of API can be a breeding ground for CSRF even with the advent of the cross-site cookie bans. I admit my answer does not clarify the conditions for successful cross-site POST cookies or the reasoning behind the transitional permission for those.
    – eel ghEEz
    May 4 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.