101–104 of 104 posts
Earlier quoted context omitted.
No, in CSRF the browser is not the adversary, it is a confused deputy, and it’s perfectly reasonable to collaborate with it against the attacker (which is another site). You might want to read https://words.filippo.io/csrf .
You might want to read https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
Earlier quoted context omitted.
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
Yes, this is documenting one particular way of doing CSRF. A specific implementation. The OP is documenting another implementation to protect against CSRF, which is unsuitable for many since it fails to protect 5% of browsers, but still an interesting look at the road ahead for CSRF and in some years perhaps everyone will change how this is done. And you say isn't OK, but have not in my opinion properly argued for wh…
You can change a setting on caniuse.com and it excludes untracked browsers. Sec-Fetch-Site goes up to 97.6, with remainder being a bit of safari (which will likely update soon) and some people still on ancient versions of chrome.
The fallback origin header goes to 99.8 coverage.
Earlier quoted context omitted.
Sorry, but you seem to be lost. I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections. None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.
"MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong. "It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...