Update: [CSRF] Mention that non-signed Double Submit Cookie tokens can be generated client & server side.

[advename]

What is missing or needs to be updated?

OWASP Double Submit cookie doesn’t mention whether the token should be generated server or client side. However, it does so for the Synchronizer token pattern.

This has historically created many doubts:

• https://stackoverflow.com/questions/2561564/client-generated-double-submit-cookie-cross-site-request-forgery-prevention
• https://stackoverflow.com/questions/69526826/is-generating-csrf-token-on-the-front-end-a-bad-idea
• https://stackoverflow.com/questions/74014826/generating-csrf-token-on-frontend-in-my-react-app
• https://www.reddit.com/r/AppSecurity/comments/dscjh0/can_i_generate_csrf_tokens_on_the_client_side_in/

Using non-signed tokens, there's no difference between generating the token server or client side, since both:

• can generate a cryptographical random value (Client side with the Web Crypto API)
• set the token in a non-HttpOnly cookie

How should this be resolved?

The Double Submit Cookie section should state more specifically that the token can be generated both server and client side for non-signed tokens, but only server-side for signed token, thus eliminating confusion.

[mackowski]

@advename good issue. Do you want to make a PR for that?

[advename]

I can try, but will take some time!