I will generate a CSRF token and include it in a hidden form field. When receiving the request, I will check the form value against the value either stored in the user's session or in a cookie.

Is it still considered acceptable from a security perspective to store this token in the cookie instead of the session?


3 Answers 3


Whilst I can't think of any direct attacks on such a system, I would argue that it's not a very good idea to put such tokens on the client side. You're opening yourself up to potential leaks. Storing them in the session makes them impossible to retrieve.

  • 4
    CSRF is usually caused by authentication cookies. Putting another cookie in there as "protection" cannot really help much.
    – AviD
    Aug 24, 2012 at 13:35
  • Can you outline a scenario in which a cookie-stored token is exploitable where a session-stored token would not be? We currently use cookie-stored tokens (secure httponly session-timeout), and if it is a problem I would like to look into fixing it.
    – csauve
    Jul 10, 2013 at 13:50
  • @csauve It's always exploitable. The cookie will be sent with the request, and will do absolutely nothing. See pgolen's answer below.
    – Polynomial
    Jul 10, 2013 at 14:00
  • @Polynomial: I think you have either misunderstood the question, or the nature of a the methodology the OP is referring to. The cookie is checked against a form value, which a third party website cannot know. See owasp.org/index.php/…
    – csauve
    Jul 10, 2013 at 17:08

Storing token in a cookie is not a solution to the CSRF problem. The CSRF vulnerability arises from the fact, that browser automatically sends cookies along with the request. As a result application considers that request as coming from valid (and authenticated) user. The only thing that attacker needs is the exact request that should be send. Introducing random Anti-CSRF token (request specific or session specific) causes it impossible (or just very difficult) to prepare valid request (in general case attacker doesn't know the valid value for anti-csrf token) and such a request will be dropped by server.

If you put your token in a cookie, it will be send to the server automatically, just as session cookie, so you don't get any additional protection from that.

EDIT: I might misunderstood your question. You may be talking about so called double submitted cookies pattern where the same value is sent in hidden field and cookie.

Yes, this approach is acceptable when storing the CSRF token in session is problematic, you can read more about this here: Double Submit Cookies .

  • Strange that this was downvoted, it is the correct answer. Except for the last sentence, which I assume is a typo - double-submitted cookies is not a good solution.
    – AviD
    Aug 24, 2012 at 13:28
  • See e.g. security.stackexchange.com/q/2078/33
    – AviD
    Aug 24, 2012 at 13:32
  • 3
    According to OWASP CSRF Prevention Cheat Sheet this approach is effective in mitigating the risk of CSRF, but it may increase the risk of session hijack. You can avoid this by using separate cookies for session and anti-csrf protection. Sometimes session is not important - i.e. public vote pools where CSRF may be used to alter vote results.
    – pgolen
    Aug 27, 2012 at 13:37
  • true, it creates risk in other areas, which is why it's not acceptable. Having separate cookies helps, but it still has problems, and is not a good solution (but comments are not the place for that :) ). That said, most frameworks today have a solution builtin, so I would be against rolling your own anyway...
    – AviD
    Aug 27, 2012 at 14:20
  • @AviD, I have a little bit different point of view. Don't get me wrong, I agree that storing anti-csrf token in session is better solution, but using double submit cookies may be good enough in some situations and is not a vulnerability by itself. And one more thing - different frameworks uses different strategy for anti-csrf token (i.e. one-time token vs. session tokens, passing token as form element vs. passing it as a additional header) so it is another topic for discussion :)
    – pgolen
    Aug 27, 2012 at 18:08

Storing it as a cookie only makes it trivial to implement replay attacks.

If it's stored in the session, then although there is a small window where replaying the same token will effect a CSRF, the window of opportunity is massively reduced - particularly if you add in some session validation (tracking user agent changes - but beware that Chrome will upgrade itself transparently mid-session - or using the organisation name from the client ip address)

  • 1
    I am a bit confused. Why would the window of opportunity differ between a cookie or session value, assuming the csrf token is updated at the same frequency in either case? Aug 23, 2012 at 15:14
  • 1
    Once the token is used, it should be invalidated for further use and a new token should be given. There's no window for replay attacks.
    – Polynomial
    Aug 23, 2012 at 15:43
  • How would you invalidate a token on use without storing a copy of it serverside?
    – symcbean
    Aug 24, 2012 at 8:47
  • Replay attacks are a totally different class of problems. You can use the token for both purposes, but don't confuse the two. You are essentially also using the token as a nonce.
    – csauve
    Jul 10, 2013 at 17:15

You must log in to answer this question.

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