How-to How to use Django’s CSRF protection

Certain views can have unusual requirements that mean they don’t fit the normal pattern envisaged here. A number of utilities can be useful in these situations. The scenarios they might be needed in are described in the following section.

Release notes Django 1.9 release notes What’s new in Django 1.9Minor features

The request header’s name used for CSRF authentication can be customized with CSRF_HEADER_NAME. The CSRF referer header is now validated against the CSRF_COOKIE_DOMAIN setting if set. See How it works for details.

Release notes Django 2.1 release notes What’s new in Django 2.1Minor features

Added the CSRF_COOKIE_SAMESITE setting to set the SameSite cookie flag on CSRF cookies.

Release notes Django 3.1 release notes What’s new in Django 3.1Minor features

The CSRF_COOKIE_SAMESITE setting now allows 'None' (string) value to explicitly state that the cookie is sent with all same-site and cross-site requests.

Release notes Django 4.0 release notes What’s new in Django 4.0Minor features

CSRF protection now consults the Origin header, if present. To facilitate this, some changes to the CSRF_TRUSTED_ORIGINS setting are required.

Release notes Django 1.3 release notes Backwards-incompatible changes in 1.3

Prior to Django 1.2.5, Django’s CSRF-prevention system exempted AJAX requests from CSRF verification; due to security issues reported to us, however, all requests are now subjected to CSRF verification.

Release notes Django 1.4 release notes What’s new in Django 1.4

We’ve made various improvements to our CSRF features, including the ensure_csrf_cookie() decorator, which can help with AJAX-heavy sites; protection for PUT and DELETE requests; and the CSRF_COOKIE_SECURE and CSRF_COOKIE_PATH settings, which can improve the security and usefulness of CSRF protection.

Release notes Django 1.4 release notes Backwards incompatible changes in 1.4

Previously, Django’s CSRF protection provided protection only against POST requests.

Release notes Django 1.8.15 release notes

An interaction between Google Analytics and Django’s cookie parsing could allow an attacker to set arbitrary cookies leading to a bypass of CSRF protection.

Release notes Django 1.9.10 release notes

An interaction between Google Analytics and Django’s cookie parsing could allow an attacker to set arbitrary cookies leading to a bypass of CSRF protection.

Release notes Django 4.0 release notes Backwards incompatible changes in 4.0

Release notes Django 1.2 release notes What’s new in Django 1.2

Django now has much improved protection against Cross-Site Request Forgery (CSRF) attacks.

Release notes Django 1.7 release notes What’s new in Django 1.7Minor features

The CSRF_COOKIE_AGE setting facilitates the use of session-based CSRF cookies.

Release notes Django 4.0 release notes Backwards incompatible changes in 4.0CSRF_TRUSTED_ORIGINS changes

Values in the CSRF_TRUSTED_ORIGINS setting must include the scheme (e.g. 'http://' or 'https://') instead of only the hostname. Also, values that started with a dot, must now also include an asterisk before the dot. For example, change '.example.com' to 'https://*.example.com'.

Release notes Django 4.0 release notes Backwards incompatible changes in 4.0CSRF_TRUSTED_ORIGINS changes

As CSRF protection now consults the Origin header, you may need to set CSRF_TRUSTED_ORIGINS, particularly if you allow requests from subdomains by setting CSRF_COOKIE_DOMAIN (or SESSION_COOKIE_DOMAIN if CSRF_USE_SESSIONS is enabled) to a value starting with a dot.

Release notes Django 1.1 release notes What’s new in Django 1.1

Other new features and changes introduced since Django 1.0 include: The CSRF protection middleware has been split into two classes – CsrfViewMiddleware checks incoming requests, and CsrfResponseMiddleware processes outgoing responses.

Release notes Django 1.6 release notes What’s new in Django 1.6

Authentication backends can raise PermissionDenied to immediately fail the authentication chain. The HttpOnly flag can be set on the CSRF cookie with CSRF_COOKIE_HTTPONLY. The assertQuerysetEqual() now checks for undefined order and raises ValueError if undefined order is spotted.

Release notes Django 1.11 release notes Features deprecated in 1.11

CSRF failures are logged to the django.security.csrf logger instead of django.request. ALLOWED_HOSTS validation is no longer disabled when running tests. If your application includes tests with custom host names, you must include those host names in ALLOWED_HOSTS.

Release notes Django 1.2 release notes

Vastly improved protection against Cross-Site Request Forgery (CSRF). A new user “messages” framework with support for cookie- and session-based message for both anonymous and authenticated users. Hooks for object-level permissions, permissions for anonymous users, and more flexible username requirements.

Release notes Django 2.1 release notes Backwards incompatible changes in 2.1

The cookies used for django.contrib.sessions, django.contrib.messages, and Django’s CSRF protection now set the SameSite flag to Lax by default. Browsers that respect this flag won’t send these cookies on cross-origin requests.