The Double Submit Cookie CSRF Token pattern is a stateless technique that doesn't require storage or a database. However, it's vulnerable to session hijacking attacks and sub-/sibling domains that are susceptible to XSS or HTML injection. A common way to mitigate this risk is by using a session value and signing it using HMAC to validate the authenticity of the request.
For backend programming languages that don't natively support sessions (such as NodeJS) or when not Database is available, JWT is commonly used with
HttpOnly Cookies to persist authorization across multiple requests. However, note that while the JWT value can't be tampered with because it's a signed value, it's not a server-side secret and can be read by the client.
Given these considerations, what value unique to a session can be used to generate the HMAC CSRF Token when using JWT?
Some possibilities I thought about were:
- attaching a random UUID in the JWT payload and encrypting the JWT, but this approach adds a lot of overhead
- use a database to store session IDs, but this negates the need for JWT in the first place.