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.
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?
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.
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.
10 comments
[ 2.7 ms ] story [ 28.9 ms ] thread> 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.
The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?
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.
Not just cookies!! Any HTTP authentication. Kerberos, NTLM, OAuth.
I'm lost here.