Cross-Site Request Forgery

28 tatersolid 4 8/13/2025, 5:31:08 PM words.filippo.io ↗

Comments (4)

akersten · 2m 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 · 3m ago
Not sure I agree with this part:

> 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.

nchmy · 49m ago
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 · 32m 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.