The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.
CSRF protection without tokens or hidden form fields
61–70 of 116 posts
Re: CSRF protection without tokens or hidden form fields
#62Earlier quoted context omitted.
No? The whole point of SameSite=(!none) is to prevent requests from unexpectedly carrying cookies, which is how CSRF attacks work.
What does this even mean? I’m not being rude, what does it mean to unexpectedly carry cookies? That’s not what I understand the risk of CSRF is. My understanding is that we want to ensure a POST came from our website and we do so with a double signed HMAC token that is present in the form AND the cookie, which is also tied to the session. What on earth is unexpectedly carrying cookies?
The "unexpected" part is that the browser automatically fills some headers on behalf of the user, that the (malicious) origin server does not have access to. For most headers it's not a problem, but cookies are more sensitive.
The core idea behind the token-based defense is to prove that the origin server had access to the value in the first place such that it could have sent it if the browser didn't add it automatically.
I tend to agree that the inclusion of cookies in cross-site requests is the wrong default. Using same-site fixes the problem at the root.
The general recommendation I saw is to have two cookies. One without same-site for read operations, this allows to gracefully handle users navigating to your site. And a second same-site cookie for state-changing operations.
Re: CSRF protection without tokens or hidden form fields
#63Earlier quoted context omitted.
Since when are they case sensitive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... says otherwise. It's possible for a server to treat them as case sensitive, but that seems like a bad idea.
>> FYI, HTTP headers are case insensitive > Since when are they case sensitive? [...]
Perhaps the OG comment was misread or confusion was caused by a typo and/or edit.
When I originally read it hours ago, I also read it as "...HTTP headers are case sensitive," (emphasis mine).
That said, there is one caveat regarding case sensitivity for headers encoded for HTTP/2.
Re: CSRF protection without tokens or hidden form fields
#64Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows: - Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options…
Yeah, redoing the defaults would probably be good.
On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.)
So the state of things for "how should web browsers work?" seems to be getting worse, not better.
Re: CSRF protection without tokens or hidden form fields
#65Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows: - Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options…
Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.
Wow, I used to be able to search google even from terminal browsers like 'elinks'
Re: CSRF protection without tokens or hidden form fields
#66Earlier quoted context omitted.
Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.
Wow, I used to be able to search google even from terminal browsers like 'elinks'
I used elinks once to find a solution to an issue where the login screen was broken after an upgrade. I was able to switch to a virtual console, find out about the issue, identify the commands to fix the issue, and use them to resolve the issue.
Re: CSRF protection without tokens or hidden form fields
#67This 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 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.
Re: CSRF protection without tokens or hidden form fields
#68This 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 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…
Without those headers, you can as a fallback compare the Origin header to the Host header.
Re: CSRF protection without tokens or hidden form fields
#69Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows: - Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options…
Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.
I think it still works if you set your user agent to something like lynx. I had a custom UA set for Google search in Firefox just for this purpose and to disable AI overviews.
Re: CSRF protection without tokens or hidden form fields
#70This 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 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…
> UX benefits of tokenless CSRF
What are those?