adevilinycDec 22

CSRF protection without tokens or hidden form fields

https://blog.miguelgrinberg.com/post/csrf-protection-without-tokens-or-hidden-form-fields

CSRF Protection without Tokens or Hidden Form Fields

A couple of months ago, I received a request from a random Internet user to add CSRF protection to my little web framework Microdot, and I thought it was a fantastic idea.When I set off to do this…

Show threadtmsbrgDec 24

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag:

https://scotthelme.co.uk/csrf-is-dead/

But I didn't know about the Sec-Fetch-Site header, good to know.

Cross-Site Request Forgery is dead!

After toiling with Cross-Site Request Forgery on the web for, well forever really, we finally have a proper solution, it's Same-Site Cookies.

Scott Helme
Show threadmiguelgrinbergDec 24
The OWASP CSRF prevention cheat sheet page does mention SameSite cookies, but they consider it defense in depth: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re....
Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

Show threadtptacekDec 25
Because of clientside Javascript CSRF, which is not a common condition.
Show threadnchmy
Client side js is not particularly relevant to csrf.
Dec 25 at 6:22amWeb
Show threadtptacekDec 25
I mostly agree, but that's the logic OWASP uses to argue you should still be doing explicit tokens even if you're using SameSite and Sec-Fetch.