That’s not correct, or is at least seriously misleading. `Sec-Fetch-Site` is a replacement for CSRF tokens. The sole purpose of CSRF tokens is to prevent CSRF,

That’s not correct, or is at least seriously misleading. `Sec-Fetch-Site` is a replacement for CSRF tokens. The sole purpose of CSRF tokens is to prevent CSRF, and enforcing that all unsafe[1]-method requests have a `Sec-Fetch-Site: same-origin` header serves exactly the same purpose – in other words, adding a CSRF token to this policy doesn’t achieve anything. The most relevant difference for most apps is that `Sec-Fetch-Site` isn’t sent by older browsers. Now, I would actually prefer to make this claim about the `Origin` header, since the spec for `Sec-Fetch-Site`[2] says that “in order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value.” But given that Go 1.25 is deploying a `Sec-Fetch-Site` check[3] as mentioned in the article and that places are recommending it as defence in depth, the `same-origin` value will probably never change in a way that’s backwards-incompatible with this kind of use. [1] in the HTTP spec sense [2] https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-si... [3] https://cs.opensource.google/go/go/+/master:src/net/http/csrf.go;l=145;drc=aa83aee7de1d69b207ab9669bb2b7dcdcbdf9383 https://cs.opensource.google/go/go/+/master:src/net/http/csr...