Consider a site enforcing the Origin header is present and set to the expected origin. An older browser or one with an extension removing the header will be rejected. SameSite=Strict cookies are used for defense in depth.
Is it sensible for this site to stop using CSRF tokens?
Conversation
You could make the argument that CSRF tokens are defense in depth, but I don't see what it adds. It was always an ugly hack and getting rid of it would be nice.
Can also enforce Sec-Fetch-Site being same-origin when present as a redundant check but it's not portable like Origin.
2
3
CSRF tokens in the HTML are particularly horrible because they prevent caching and the user can accidentally leak them via the page source.
Prior to Origin/Sec-Fetch-Site, there weren't really cleaner ways of preventing CSRF for non-authenticated APIs like a sign in form though.
Replying to
I'm seeing them going away w/ REST APIs and responsive front-ends. They made more sense for server-side rendered pages.
This Tweet was deleted by the Tweet author. Learn more
Replying to
What I mean by caching is "Cache-Control: public, no-cache" with all HTML served from a static web server. Browser checks that it has the latest copy (ETag, Last-Modified) and usually gets a 304.
CSS, JS and other static assets get cached indefinitely via immutable attribute.
1
Show replies