Cookies have been truly horrible. I check in on them every couple of years, because I don't do a lot of front-end but when I do it's often security-sensitive, and every single time I check in on them there's some new entry in "SameSite; NoSeriouslySecureHarder; WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure; AwwShitDidWeGetItRightLastTime=false" parade of attributes you need to send to get actually secure cookies.

No shade on the people implementing this stuff, I understand the backwards compatibility concerns, but I mean, keeping up with this stuff is harder than it should be. And thanks to backwards compatibility most of it still defaults open, though browsers have pecked at that as they can.

IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.

Those apps are beyond helping already. They need to fix theselves.

The entire WordPress ecosystem says hello

This is on the server side, on the app. If your supposedly-safe methods aren't safe, then CSRF may not be your biggest problem.

That’s bad because visiting an evil site can easily trick your browser into performing one of those requests using your own credentials. CORS doesn’t stop the backend state effect from happening.

The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com and https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com to be able to make requests to https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.

Same-Site cookies are, well, same-site. Not same-origin. This is already a deal-breaker for many deployments, because they don't trust blog.example.com and partner.example.com as much as admin.example.com (both in the strict sense of trust, and in the senso of not having XSS vulnerabilities the attacker can pivot off).

Worse, by the original definition http://foo.example.com and https://admin.example.com are same-site, and unless the site uses HSTS with includeSubDomains, any network attacker controls the former. Chrome changed that with Schemeful Same-Site in 2020, but Firefox and Safari never deployed it.

The other replies answer this question, but it’s worth mentioning the public suffix list which contains a list of domain suffixes that have subdomains that are controlled by different people. E.g github.io, wordpress.com

Browser use this list to prevent cookie shared between sites using the suffixes on the list. E.g evil.github.io will not receive cookies from nice.github.io, or any other .github.io origin, regardless of the SameSite attribute

A few more links that I collected recently on the topic

https://github.com/golang/go/issues/73626

https://developer.mozilla.org/en-US/docs/Web/Security/Attack...

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

https://web.dev/articles/fetch-metadata

https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/

And some older ones that focused on Origin header rather than sec-fetch-*

https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with...

https://www.brandur.org/fragments/origin

https://srungta.github.io/blog/start-right/ui-nonce