CSRF stands for Cross-Site Request Forgery. It was rather popular in the earlier internet but now it’s almost a non-issue thanks to standard prevention mechanisms built into most of popular web frameworks. So I knew about it but never thought too much and assumed it just works. It does, but understanding why it does required me to R more than one FM.

According to OWASP,

A Cross-Site Request Forgery (CSRF) attack occurs when a malicious web site, email, blog, instant message, or program tricks an authenticated user’s web browser into performing an unwanted action on a trusted site. […] unprotected target sites cannot distinguish between legitimate authorized requests and forged authenticated requests.

Since browser requests automatically include all cookies including session cookies, this attack works unless proper authorization is used, which means that the target site’s challenge-response mechanism does not verify the identity and authority of the requester. In effect, CSRF attacks make a target system perform attacker-specified functions via the victim’s browser without the victim’s knowledge (normally until after the unauthorized actions have been committed).

However, successful CSRF attacks can only exploit the capabilities exposed by the vulnerable application and the user’s privileges. Depending on the user’s credentials, the attacker can transfer funds, change a password, make an unauthorized purchase, elevate privileges for a target account, or take any action that the user is permitted to do.

Preventing CSRF means making sure the request is not cross-site, i.e. the request origin is the same as the target, i.e you were on the same site you are sending the request to.

Like all the things making sure, it requires a secret token that is associated with user. If we send forms without javascript involved, the token can be put into a form as a hidden input. Otherwise, the key is typically put into a <meta> tag, or a cookie, and then some javascript gets it from there and puts into requests.

A cookie?

Cookies are set for a specific domain or a domain with its’ subdomains. There is a Domain attribute for the Set-Cookie header, and not setting it is the strictest option possible. There are other attributes and prefixes that ensure other things. Rather ironically, Secure only means that the request to set cookie was sent using https.

Other notable attributes are SameSite and HttpOnly.

So if you put a CSRF token into a cookie, it can only be read from the same domain and you are safe, unless there are subdomains that you don’t control. It shouldn’t be HttpOnly if you want to read it from JS.

Do I have to read it from JS?

In the beginning on 2025, yes, sadly.

There is SameSite attribue for the set-cookie header that may change it in the future. This attribute is about whether the cookie should be included into a request depending on the origin. The default value is Lax, and it demands the browser to send the cookie for the same-site requests, and for the “safe” cross-origin requests. The latter means GET requests from other websites. Strict doesn’t put the cookie into any cross-origin requests.

In theory, this allows to not use the special token at all and only authorise user with a session cookie. The catch is it’s a rather new thing and not all the browsers support that. 96% do, but it’s not that we want the other 4% be vulnerable to that.

Why do we need another token? Can’t we use session cookie for that?

Session cookie, or session identifier cookie, should be set with HttpOnly attribute. This would prevent it from being read in javascript and give us a bit of Swiss cheese security. In case of a successful cross-site scripting attack your CSRF token will be compromised but the session won’t. In case of XSS you are in a pretty big trouble anyway, but when the vulnerability is fixed, CSRF tokens can be rotated, which is less of a nuisanse than logging everyone out.

What prevents a cookie to be read or written against the rules?

Browsers. We expect browsers to comply with so many things. It won’t allow to read cookies for the wrong domain, it won’t allow to read HttpOnly cookies in javascript, it won’t send a cookie into a cross-site request if SameSite forbids that. Browsers also update automatically these days, but some people still use Opera mini from 2015 and UCBrowser that doesn’t support anything which prevents us all from having nice things.

Can I send a GET request from another domain?

Yes, but you won’t get a response. Browsers also comply with the Same-origin policy. In this policy, writes are typically allowed, and reads typically aren’t.

As a site developer, you can control this. There is Access-Control-Allow-Origin response header for that, it tells browser only to show the response to the allowed origins. For example, you can allow any origin by setting it to *. This is useful if you are a CDN, but you really shouldn’t do that if you send an anti-CSRF token in the response.

Also, the good part of write requests need a preflight request first. Before sending a POST, browser sends an OPTIONS request, get the access control headers and decides if it’s even allowed.

Why not all of the write requests have a preflight? Because the internet standards are backward-compatible more than most, and the <form> element existed before preflight requests were introduced. There is even a suggestion to make your server disallow simple requests altogether. This would mean that form submit won’t work, but you also won’t have to use tokens because every request is pre-flighted now.

The whole part of the HTTP spec about selectively allowing cross-site requests is called CORS, which stands for Cross-Origin Resource Sharing. Naming is hard.

BTW, remember we said that headers for another domain can’t be read from JS? They can’t, but you can allow to send them in a cross-site request. The preflight response header for that would be Access-Control-Allow-Headers.

Can’t server just check request origin?

Origin is another header, and it belongs to the Fobidden Headers List. Those are headers that can’t be set programmatically, only browser sets them.

It seems that Origin header is always set in https cross-origin requests. It’s also set in many other cases but this is mostly what we check for. Browser may trim Origin headers if a request goes through redirect, but redirect can’t be POST.

The reason seems to be that this way we don’t have to trust browsers. OWASP again:

Should a browser bug allow custom HTTP headers, or not enforce preflight on non-simple content types, it could compromise your security. Although unlikely, it is prudent to consider this in your threat model. Implementing CSRF tokens adds additional layer of defence and gives developers more control over security of the application.

What doesn’t add up for me is that we suddenly stop trusting browser for this case, but trust it on the Same-origin policy that prevents a malicious website from sending a GET request and reading the token from response. My guess is, it’s a complex system, and bugs can be subtle, so better be safe than sorry.

I’m also slightly suspicious about abusing origin information for user tracking. I’ve read about browsers sending less info in Referer header for privacy reasons but haven’t found anything similar about Origin.

Overall, I’d be grateful for a better answer for this question.

Why do we rotate CSRF tokens?

OWASP says

Because the time range for an attacker to exploit the stolen tokens is minimal for per-request tokens, they are more secure than per-session tokens.

This doesn’t sound like a good reason to me. If a token is compromised you might as well think all the malicious requests are made the next second or two when user who did all the very suspicious actions required to give up the token clicks the last required button.

This comes into the same bucket of why we rotate sessions. Google doesn’t even log me out but some sites do. I wonder what OWASP people think of that.

Appreciate comments on this one as well.

Conclusion

CSRF prevention is putting into the request something that can only be read from the same origin. Write authorization based on read authorization, if you like.

The future will be bright when 100% of browsers that people use will support SameSite attribute. Until then, we have a rather complex but rather elegant system to prevent unwanted cross-site requests. And I still don’t fully understand what’s wrong with checking request origin.