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.
1
2
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.
It's a whole lot slower and messier if you're serving it from an application server. I greatly prefer a design where all the HTML is static and anything dynamic is handled via APIs. Dynamically constructing HTML on either client or server is very error prone and bad for security.
1
I highly value having require-trusted-types-for 'script'; trusted-types 'none' on the client and aiming to uphold the same thing for the server too.
Dynamically setting a CSRF token in the HTML is a mild violation of the rule and also gets leaked via saving page source, etc.