I am trying to figure out if the solution I am suggesting is valid for both XSS & CSRF protection,

I would like to store the JWT in an httpOnly & secure cookie and not in local storage, when the user successfully logs in, he will get (in addition to the cookie) a CSRF token(random string) in the response payload, same token is being added as a claim to the JWT payload, on user side token will be stored in localStorage.

When user calls an authenticated rest endpoint he attached the CSRF token as a header("csrf-token": "randomToken" header) as we are stateless all request will first validate the JWT signature, and after the validation the code will check if the token in the JWT payload is equal to the one in the request header.

As I didn't find any proposition for this sort of a solution I am suspecting this is not 100% hack proof, but I can't understand why, any help would be appreciated,

Many thanks

  • Nobody? I really don't want to test it in production...
    – Roie Beck
    Dec 25, 2021 at 14:41

1 Answer 1


The CSRF token is used to validate the client request with a trusted source. If you decide to store the CSRF token in the JWT data, that's okay. A regular usage of CSRF would be returned on the client somewhere before a request and then sent to the server and verified with the client session (in your case JWT). See this explanation from PortSwigger:

When a CSRF token is generated, it should be stored server-side within the user's session data. When a subsequent request is received that requires validation, the server-side application should verify that the request includes a token which matches the value that was stored in the user's session. This validation must be performed regardless of the HTTP method or content type of the request. If the request does not contain any token at all, it should be rejected in the same way as when an invalid token is present.

Since it seems you answer the requirement of verifying the token from a trusted source (assuming your JWT implementation is secure), this should be okay. The only concern I would have with your method is the expiration and refresh of the CSRF token. Remember these tokens should be used once and regenerated per request so they can't be re-used.

  • 1
    thanks, I didn't know csrf are single time use, with that in mind the best solution is indeed the refresh token in local storage -> access token in cookie(and each time invalidate the token) solution, this is probably the most secure method, but it is a long flow and I wanted to save the back and forth on each request, you are correct, in my case the CSRF will not be single time token but will live as long as the JWT is not expired, but while not being the most secure, it is a better solution than normal JWT in cookie, and does provide additional protection...
    – Roie Beck
    Dec 26, 2021 at 11:02

You must log in to answer this question.

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