When a client makes the first request, I send a session ID cookie generated by the server as a string of 64 random bytes using getrandom(2) or /dev/urandom, stored in the database, with the flags HttpOnly, Secure and SameSite=Strict set. Additionally, the server sends a Content-Security-Policy header with the value default-src 'none'; script-src 'self'; connect-src 'self'; style-src 'self'; img-src 'self', base-uri 'self'; form-action 'self'; frame-ancestors 'none', and it doesn't send any Access-Control-Allow-Origin header. I have no subdomains, all state changing requests are POST requests, and all data is properly escaped, which makes XSS impossible.

If a client makes a request in the future, I check if the request contains a session ID cookie and if that session ID is in the database, otherwise I ignore the session ID they send and create a new one as described above.

In this scenario, what advantages would a CSRF token provide, if I want to protect against someone impersonating someone else?

I can't think of any way in which an attacker would be able to send a request that the server would think belongs to another user. In order to do that, they'd need the user's session ID, and I can't see how they could obtain it, unless the user uses an old browser which doesn't understand the cookie flags or the Content-Security-Policy header, but I can protect against that by requiring the user to use a browser version known to support both.

If the CSRF token indeed doesn't provide any extra layer of security for the purposes of defending against impersonation, is there any other benefit of using a CSRF token in this scenario?

  • As you noted, not all browsers support the SameSite attribute caniuse.com/same-site-cookie-attribute so your site would still be vulnerable for people using those browsers. Other than that yeah, SameSite=Strict is enough.
    – Ajedi32
    Jul 13 at 20:33

Yes, you still need it.

Yes, I can’t think of a way to break your site today, but that isn’t the security question, and this is a security site.

No, there are no other security benefits to using a csrf token. You could look at crypto systems that use nonces, or anti-replay stuff but that’s not what the csrf is doing.

The security question is should I use CSRF to keep my site safe? Yes you should because it’s an extra layer that costs nothing.

That makes this a risk question. Is the cost of the mitigation greater than or less than the cost of the risk?

(Also you must evaluate whether the mitigation is more harmful or less harmful than the risk. Otherwise you force people to rotate passwords every 90 days because everyone does it - even though it’s more harmful than not rotating them)

Reasons to do it:

  1. If it breaks, we don’t know what will break, or what the impact will be. I can’t think of a way to break this but risk is impact AND probably. This point is the impact is not known.

  2. The sheer number of things you have to do to get the site to a state where csrf is probably safe tells me:

2.a. at some point now or into the future, somebody will make a mistake.

2.b. I don’t know if the browser developers have actually tested all of these states on all of the browsers.

So the probability that someone will mess up one of these numerous defenses - either someone working on your code, or someone working on the browsers, is medium. (Tough to argue it probably won’t happen. Tough to argue it will.)

Typically an unknown impact.

An unknown impact and a medium probably is a high risk.

Since csrf is easy (code in every popular browser and backend I’ve used in the last few years), I believe continuing to use CSRF is the right path forward.

Further, and this is a stretch - consider that it’s easy to do the csrf stuff, and it’s practically ubiquitous. it’s possible that browser developers may not prioritize bugs in the other solutions. This might leave your implementation vulnerable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.