Reference Built-in template tags and filters Built-in tag reference

This tag is used for CSRF protection, as described in the documentation for Cross Site Request Forgeries.

How-to How to use Django’s CSRF protection Using CSRF protection with AJAX

The recommended source for the token is the csrftoken cookie, which will be set if you’ve enabled CSRF protection for your views as outlined above.

How-to How to use Django’s CSRF protection Using CSRF protection with AJAX

If you activate CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY, you must include the CSRF token in your HTML and read the token from the DOM with JavaScript:

How-to How to use Django’s CSRF protection Edge cases

There may be some views that are unprotected and have been exempted by csrf_exempt, but still need to include the CSRF token. Solution: use csrf_exempt() followed by requires_csrf_token(). (i.e. requires_csrf_token should be the innermost decorator).

Reference Cross Site Request Forgery protection Frequently Asked Questions

No, this is by design. Without a man-in-the-middle attack, there is no way for an attacker to send a CSRF token cookie to a victim’s browser, so a successful attack would need to obtain the victim’s browser’s cookie via XSS …

How-to How to use Django’s CSRF protection Using CSRF protection with AJAX

Finally, you’ll need to set the header on your AJAX request. Using the fetch() API:

How-to How to use Django’s CSRF protection

If the csrf_token template tag is used by a template (or the get_token function is called some other way), CsrfViewMiddleware will add a cookie and a Vary: Cookie header to the response.

6.0 dev

How-to How to use Django’s CSRF protection Edge cases

There are cases when CsrfViewMiddleware.process_view may not have run before your view is run - 404 and 500 handlers, for example - but you still need the CSRF token in a form. Solution: use requires_csrf_token()

Reference Settings Core Settings

Default: False Whether to store the CSRF token in the user’s session instead of in a cookie. It requires the use of django.contrib.sessions.

How-to How to use Django’s CSRF protection

If the csrf_token template tag is used by a template (or the get_token function is called some other way), CsrfViewMiddleware will add a cookie and a Vary: Cookie header to the response.

4.2 5.0 5.1 5.2

Reference The Django template language: for Python programmers Playing with Context objectsBuilt-in template context processors

This processor adds a token that is needed by the csrf_token template tag for protection against Cross Site Request Forgeries. This is always enabled by RequestContext and cannot be disabled. You do not need to include it within context_processors.

How-to How to use Django’s CSRF protection

While the above method can be used for AJAX POST requests, it has some inconveniences: you have to remember to pass the CSRF token in as POST data with every POST request.

How-to How to use Django’s CSRF protection

Django’s Jinja2 template backend adds {{ csrf_input }} to the context of all templates which is equivalent to {% csrf_token %} in the Django template language. For example:

Reference Settings Core Settings

Default: False Whether to use HttpOnly flag on the CSRF cookie. If this is set to True, client-side JavaScript will not be able to access the CSRF cookie.

How-to How to use Django’s CSRF protection

The CsrfViewMiddleware will usually be a big hindrance to testing view functions, due to the need for the CSRF token which must be sent with every POST request.

Reference Cross Site Request Forgery protection Frequently Asked Questions

For security reasons, CSRF tokens are rotated each time a user logs in. Any page with a form generated before a login will have an old, invalid CSRF token and need to be reloaded.

How-to

To take advantage of CSRF protection in your views, follow these steps: The CSRF middleware is activated by default in the MIDDLEWARE setting.

Reference Cross Site Request Forgery protection Frequently Asked Questions

No, this is by design. Not linking CSRF protection to a session allows using the protection on sites such as a pastebin that allow submissions from anonymous users which don’t have a session.

Reference Cross Site Request Forgery protection

The CSRF protection is based on the following things: A CSRF cookie that is a random secret value, which other sites will not have access to. CsrfViewMiddleware sends this cookie with the response whenever django.middleware.csrf.get_token() is called.

How-to How to use Django’s CSRF protection Edge cases

A page makes a POST request via AJAX, and the page does not have an HTML form with a csrf_token that would cause the required CSRF cookie to be sent. Solution: use ensure_csrf_cookie() on the view that sends the page.