# Generate CSRF Token from frontend

**URL:** <https://forum.djangoproject.com/t/generate-csrf-token-from-frontend/25129>\
**Category:** Forms & APIs\
**Created:** [November 7, 2023, 11:46pm UTC](https://forum.djangoproject.com/t/generate-csrf-token-from-frontend/25129 "2023-11-07T23:46:32Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![c4ffein](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/c4ffein/32/16899_2.png) [@c4ffein](https://forum.djangoproject.com/u/c4ffein)\
**Post date:** [November 7, 2023, 11:46pm UTC](https://forum.djangoproject.com/t/generate-csrf-token-from-frontend/25129/1 "2023-11-07T23:46:32Z")

</div>

Hi, what I am going to ask is a bit unconventional, but:  
According to [that part of the Django CSRF documentation](https://docs.djangoproject.com/en/4.2/ref/csrf/#is-posting-an-arbitrary-csrf-token-pair-cookie-and-post-data-a-vulnerability), it is ok to post an arbitrary CSRF token pair

Does that mean, as I expect, that it is safe to generate and use a random CSRF token (through a reimplementation of how it is generated from Django) from a browser SPA before each request?

I already have a working PoC, I’m hesitating to clean and publish it as a standalone lib, but I don’t want to do it if:

- this is actually insecure
- this could break without notice from any Django update as the methods responsible for token generation are supposed to be used internally (it would be ok to me if that was at least considered a breaking change and I would be sure it would end-up in the changelog, but I don’t think that would be the case, as the frontend isn’t supposed to know the nature of the CSRF Token it handles)

Thanks in advance

---

<div class="post-metadata">

**Author:** ![KaczuH](https://avatars.discourse-cdn.com/v4/letter/k/8491ac/32.png) [@KaczuH](https://forum.djangoproject.com/u/KaczuH)\
**Post date:** [November 10, 2023, 8:49am UTC](https://forum.djangoproject.com/t/generate-csrf-token-from-frontend/25129/2 "2023-11-10T08:49:07Z")

</div>

As long as you can generate cryptographically strong token on frontend it should be fine.

Digging into sources:  
[Django documentation - Is posting an arbitrary CSRF token pair (cookie and POST data) a vulnerability?](https://docs.djangoproject.com/en/4.2/ref/csrf/#is-posting-an-arbitrary-csrf-token-pair-cookie-and-post-data-a-vulnerability)  
The FAQ you refer to seems to confirm that

There is a good post on SO also:  
[Stack Overflow Django CSRF](https://stackoverflow.com/a/64160362/9820085)

Which points to Google Groups discussion where Django security team member explains the details and reasoning behind the implementation. I recommend the full read of it.

---

<div class="post-metadata">

**Author:** ![c4ffein](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/c4ffein/32/16899_2.png) [@c4ffein](https://forum.djangoproject.com/u/c4ffein)\
**Post date:** [November 11, 2023, 8:18pm UTC](https://forum.djangoproject.com/t/generate-csrf-token-from-frontend/25129/3 "2023-11-11T20:18:40Z")

</div>

Exactly, my link was directly pointing to that specific subsection

That’s why it also seemed secure to me to generate it frontend-side, but you never know… I’d rather ask anyway, thanks for your answer

My only fear now is that the way Django generates and consumes those tokens could change in a higher version (what ends-up being stored in the cookies is not just a random string)  
I’ll probably just add a way to automatically check that if I end-up releasing that lib, thank you