  this if you know what you are doing. There are other :ref:`limitations
  <csrf-limitations>` if your site has subdomains that are outside of your
  control.
  
  :ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
  POST request. This ensures that a malicious user cannot simply "replay" a form
  POST to your website and have another logged in user unwittingly submit that
  form. The malicious user would have to know the nonce, which is user specific
  (using a cookie).
  
 
</s> remove form. The malicious user would have to know the nonce, which is user specific
 </s> add form. The malicious user would have to know the secret, which is user specific </s> remove Why not use a new token for each request?
-----------------------------------------

Generating a new token for each request is problematic from a UI perspective
because it invalidates all previous forms. Most users would be very unhappy to
find that opening a new tab on your site has invalidated the form they had
just spent time filling out in another tab or that a form they accessed via
the back button could not be filled out.

 </s> add  </s> remove    when using a session independent nonce, due to the fact that HTTP
 </s> add    when using a session independent secret, due to the fact that HTTP </s> remove    outgoing POST forms.  The value of this field is the value of the CSRF
   cookie.
 </s> add    outgoing POST forms. The value of this field is, again, the value of the
   secret, with a salt which is both added to it and used to scramble it. The
   salt is regenerated on every call to ``get_token()`` so that the form field
   value is changed in every such response.
:ref:`CSRF protection works <how-csrf-works>` by checking for a secret in each
  this if you know what you are doing. There are other :ref:`limitations
  <csrf-limitations>` if your site has subdomains that are outside of your
  control.
  
:ref:`CSRF protection works <how-csrf-works>` by checking for a secret in each
  POST request. This ensures that a malicious user cannot simply "replay" a form
  POST to your website and have another logged in user unwittingly submit that
  form. The malicious user would have to know the nonce, which is user specific
  (using a cookie).
  
keep keep keep keep replace keep keep keep keep keep
 Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them

Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).

While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).

Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews. 
docs/topics/security.txt