I think I have this sorted, but would love to hear if I'm wrong. We have a Python+Angular.js set of apps, which are using JWT tokens for authentication, where the tokens are encrypted using a secret key, the payload identifies the user, and the token is stored client side in a cookie set as HTTP ONLY and as secure. For a variety of reasons this works well for us, we get to use one Python wsgi middleware app across multiple API backends, our token gets sent automatically on every request to the domain, and we get to bypass using sessions entirely. I've had this part checked out on here and elsewhere and I'm confident it's good. ( my question on that is here: http_only for cookies with JWT tokens )

My new question is how to handle CSRF tokens, given that we are not using sessions at all. I am thinking the following:

  • auth is handled off the jwt token in the cookie described above, let's call it accept_token_cookie. JS can't read it, it's HTTP ONLY. Has the user id.
  • a second cookie is sent with our CSRF token, which is not HTTP_ONLY, thus angular can read it (let's call it csrf_cookie)
  • csrf_cookies payload is an encryption of our identity payload (or part of it, like user email), but made with a second secret key
  • when an XHR request is made, my JS will look at the csrf_cookie value, and add it to a header
  • on ingress, our server decodes both cookies and gets the token as sent by angular in a custom header. If these do not all match, we know this request is bad because the requesting javascript couldn't read our csrf_cookie. However, csrf_cookie is still not used at all to generate identity, which is what we want so that the accept_token cookie remains totally opaque to the client.

From all my reading, the above sounds correct. If I'm wrong, please tell me why, thanks.

  • are your tokens for authentiction unique for each request?
    – hmrojas.p
    Commented Dec 29, 2016 at 15:09
  • When you say "on ingress, our server decodes both cookies" - is the token in a normal cookie header, and the csrf value in a custom header set by js?
    – Michael
    Commented Jan 6, 2017 at 0:00
  • Hi Michael, yes that's correct. The regular JWT token is http_only and comes in as a normal cookie. The Angular app takes the token value from the other JS readable cookie and adds it to the request headers as a custom header. The middleware compares these to make sure they match. Commented Jan 6, 2017 at 3:25
  • The authentication is not unique for each request, but rather both are set to expire in an hour and get renewed on each request. As one is readble, the client can use that one to determine how long someone has before being auto logged out. Commented Jan 6, 2017 at 3:26
  • edited original question to clarify the comparison is of a custom header and the values in the cookies. Commented Jan 6, 2017 at 3:30

1 Answer 1


when an XHR request is made, my JS will look at the csrf_cookie value, and add it to a header

If you are not using CORS and you are checking this header server-side then this alone will be enough to mitigate CSRF.

The reason is that custom headers cannot be sent cross-domain without CORS.

Setting and checking the actual token value helps further because any vulnerabilities present in plugins (e.g. Flash) that may help bypass the custom header restriction cannot be leveraged to bypass your protection.

See here for using custom headers as a CSRF mitigation.

Your approach seems like a variation of the Encrypted Token Pattern.

You must log in to answer this question.

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