[magmostafa]

This approach using Sec-Fetch-* headers is elegant, but it's worth noting the browser support considerations. According to caniuse, Sec-Fetch-Site has ~95% global coverage (missing Safari < 15.4 and older browsers).

For production systems, a layered defense works best: use Sec-Fetch-Site as primary protection for modern browsers, with SameSite cookies as fallback, and traditional CSRF tokens for legacy clients. This way you get the UX benefits of tokenless CSRF for most users while maintaining security across the board.

The OWASP CSRF cheat sheet now recommends this defense-in-depth approach. It's especially valuable for APIs where token management adds significant complexity to client implementations.

[nchmy]

98% coverage if you exclude browsers that caniuse doesn't track (which is surely appropriate, since even things like checkbox elements have only 96% coverage if you include un tracked browsers).

And you can fall back to origin header, which has universal coverage. Then block anything else.

Also, owasp doesn't recommend it as defense in depth. It is a primary, standalone defense against CSRF.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

[mxey]

Without those headers, you can as a fallback compare the Origin header to the Host header.

See https://words.filippo.io/csrf/

[yread]

> UX benefits of tokenless CSRF

What are those?