> These are safe methods, and are assumed not to change state at various layers of the stack already.
Plenty of apps violate this assumption and do allow GET requests to alter state.
chrisfosterelli · 14h ago
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.
pstuart · 13h ago
Agreed. Those methods should be treated as idempotent.
almog · 13h ago
> Those methods should be treated as idempotent
Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
Mavvie · 12h ago
Indeed, the correct term here is nullipotent.
paulhodge · 5h ago
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.
simonw · 12h ago
Those apps are beyond helping already. They need to fix theselves.
cryptonector · 6h ago
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.
nchmy · 12h ago
The entire WordPress ecosystem says hello
fabian2k · 12h ago
So am I understanding it right that you don't need any CSRF tokens anymore to fully protect against CSRF attacks?
And if Go is implementing this specific protection, are other ecosystems doing this as well? My specific interest would be .NET/C#, but I am wondering in general how widespread this specific solution is at the moment.
akersten · 14h ago
I'm not really grokking the explanation in the article of why the SameSite cookie attribute doesn't fix CSRF. I thought that was the whole design intent of SameSite=Secure on an HTTPS cookie, was to fix CSRF. Can someone boil it down?
The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?
MajesticHobo2 · 14h ago
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.
edoceo · 10h ago
This doesn't match my experience. What am I doing different?
Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)
FiloSottile · 10h ago
For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com).
FiloSottile · 11h ago
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.
pluto_modadic · 8h ago
ah, that explains it.
harg · 2h ago
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
AgentME · 13h ago
It's very nice to have an up-to-date writeup like this. I've gotten some odd looks for telling people that classic CSRF tokens are unnecessary work since the Origin header became widely supported, and I'm glad to have a page like this to refer people to.
nchmy · 12h ago
A few more links that I collected recently on the topic
i just discovered the Sec-Fetch stuff recently, due to Go 1.25's changelog. Very excited to start using it in some applications where tokens are currently used - what a hassle to deal with those.
jerf · 15h ago
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.
unethical_ban · 13h ago
Your examples made me chuckle. I was thinking "God I hope frameworks deal with all this stuff".
pstuart · 13h ago
Fortunately the stability and consistency of JS frameworks make light work of that pain!
cryptonector · 6h ago
> Essentially all applications that use cookies for authentication need to protect against CSRF.
Not just cookies!! Any HTTP authentication. Kerberos, NTLM, OAuth.
> Allow all GET, HEAD, or OPTIONS requests.
> These are safe methods, and are assumed not to change state at various layers of the stack already.
Plenty of apps violate this assumption and do allow GET requests to alter state.
Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
And if Go is implementing this specific protection, are other ecosystems doing this as well? My specific interest would be .NET/C#, but I am wondering in general how widespread this specific solution is at the moment.
The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?
Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)
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.
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
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
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.
Not just cookies!! Any HTTP authentication. Kerberos, NTLM, OAuth.
I'm lost here.