According to OWASP:

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id.

(emphasis mine)

Why does the CSRF token need to be stored in a separate cookie if the session id is:

  • a random value (a value the attacker cannot guess)
  • stored in a cookie (a value the attacker cannot read)
  • generated by the server (a value the attacker cannot write)

Why not simply use the session id as the CSRF token? You'd still submit the value twice (once in the cookie, once in the form) and compare the values, but wouldn't use a separate cookie for the CSRF token.

2 Answers 2


The reason is that this allows the main session cookie to be marked HttpOnly (so it won't be accessible to Javascript). There is some debate about how much value this adds, but HttpOnly seems to make some kinds of attacks harder so is arguably a useful hardening measure.

If you didn't use a separate cookie, but just re-used the session ID for these purposes, then Javascript would need the ability to read the session cookie, and we wouldn't be able to mark the session cookie HttpOnly. By using a separate value, it becomes possible to mark the session cookie HttpOnly.

This is why they recommend using a separate value.


There are a couple of reasons I can think of:

  • If the CSRF token is leaked, it doesn't leak the authentication cookie.
  • It allows you to set the authentication token as HTTP-only and still have a CSRF value that can be read by JavaScript to build AJAX Requests

Personally, I don't believe the double-submit cookies technique is very effective. While it's not a general CSRF, if I can MITM plain-text traffic of the user, I can then perform CSRF against https-only sites. This is done by injecting an iframe or img with the origin of the site under attack, then responding to the iframe or img with a CSRF cookie of my own, and finally by generating the cross-site request. (Yes, it requires a MITM of the user, but allows to perform a plaintext MITM attack on a site that's served over SSL only without HSTS. Using HSTS mitigates this attack, as pointed out by Gili.)

  • 3
    Aren't all CSRF protections vulnerable to MiTM attacks? Secondly, as I covered at security.stackexchange.com/a/61039/5002 using HTTPS with the HSTS header should protect against such attacks.
    – Gili
    Commented Jun 16, 2014 at 4:18
  • 1
    HSTS absolutely does protect against this attack (didn't see your other post), but since HSTS adoption is not widespread, it's worth noting. And assuming that the MITM is not against SSL and the site never serves the CSRF token over HTTP, then most CSRF protections are not MITM vulnerable.
    – David
    Commented Jun 16, 2014 at 4:25
  • I'm a little confused. Which CSRF techniques do not "serve the CSRF token over HTTP"?
    – Gili
    Commented Jun 16, 2014 at 4:35
  • 1
    I was differentiating HTTP vs HTTPS. Unless there's an SSL MITM, not serving the token over plaintext protects the token from the attacker. If an attacker has an SSL MITM, they don't need a CSRF, they can just steal the auth token. The double-submit pattern allows an attacker to set their own CSRF token, other patterns need a token validated against something server-side.
    – David
    Commented Jun 16, 2014 at 4:41
  • 1
    @Gili, David is talking about a SSL strippiung attack (the MITM redirects you to HTTP, even though the site actually uses HTTPS). If the site uses HTTPS and puts CSRF tokens in hidden form fields or in URL parameters, it'll be safe against that kind of CSRF attack -- but if the site uses HTTPS (but not HSTS) and uses cookie double-submission, it'll be vulnerable. A valid defense is to put the secure flag on all cookies: the session cookie, and also any cookies that are used for CSRF (and ideally use HSTS too).
    – D.W.
    Commented Jun 27, 2014 at 17:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .