Release notes Django 4.1 release notes Features deprecated in 4.1

Logging out via GET requests to the built-in logout view is deprecated. Use POST requests instead.

Release notes Django 1.5 release notes Backwards incompatible changes in 1.5

The csrf_token template tag is no longer enclosed in a div. If you need HTML validation against pre-HTML5 Strict DTDs, you should add a div around it in your pages.

Reference Settings Core Settings

Default: 'csrftoken' The name of the cookie to use for the CSRF authentication token. This can be whatever you want (as long as it’s different from the other cookie names in your application). See Cross Site Request Forgery protection.

Reference Settings Core Settings

Default: 'HTTP_X_CSRFTOKEN' The name of the request header used for CSRF authentication.

Reference Cross Site Request Forgery protection

Subdomains within a site will be able to set cookies on the client for the whole domain. By setting the cookie and using a corresponding token, subdomains will be able to circumvent the CSRF protection.

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

The default CSRF_FAILURE_VIEW, views.csrf.csrf_failure() now accepts an optional template_name parameter, defaulting to '403_csrf.html', to control the template used to render the page.

Release notes Django 1.9.2 release notes

Fixed a crash when destroying an existing test database on MySQL or PostgreSQL (#26096). Fixed CSRF cookie check on POST requests when USE_X_FORWARDED_PORT=True (#26094). Fixed a QuerySet.order_by() crash when ordering by a relational field of a ManyToManyField through model (#26092).

How-to How to use Django’s CSRF protection

Because it is possible for the developer to turn off the CsrfViewMiddleware, all relevant views in contrib apps use the csrf_protect decorator to ensure the security of these applications against CSRF.

How-to Deployment checklist HTTPS

Set this to True to avoid transmitting the CSRF cookie over HTTP accidentally.

Reference Middleware Available middleware

classCsrfViewMiddleware[source] Adds protection against Cross Site Request Forgeries by adding hidden form fields to POST forms and checking requests for the correct value. See the Cross Site Request Forgery protection documentation.

Reference Settings Core Settings

Default: 31449600 (approximately 1 year, in seconds) The age of CSRF cookies, in seconds.

Reference Settings Core Settings

Default: None The domain to be used when setting the CSRF cookie. This can be useful for easily allowing cross-subdomain requests to be excluded from the normal cross site request forgery protection.

Reference Settings Core Settings

Default: '/' The path set on the CSRF cookie. This should either match the URL path of your Django installation or be a parent of that path.

Reference Settings Core Settings

Default: 'Lax' The value of the SameSite flag on the CSRF cookie. This flag prevents the cookie from being sent in cross-site requests. See SESSION_COOKIE_SAMESITE for details about SameSite.

Reference Settings Core Settings

Default: False Whether to use a secure cookie for the CSRF cookie. If this is set to True, the cookie will be marked as “secure”, which means browsers may ensure that the cookie is only sent with an HTTPS connection.

Reference Settings Core Settings

Default: 'django.views.csrf.csrf_failure' A dotted path to the view function to be used when an incoming request is rejected by the CSRF protection.

Reference Settings Core Settings

Default: [] (Empty list) A list of trusted origins for unsafe requests (e.g. POST). For requests that include the Origin header, Django’s CSRF protection requires that header match the origin present in the Host header.

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

Most views requires CSRF protection, but a few do not. Solution: rather than disabling the middleware and applying csrf_protect to all the views that need it, enable the middleware and use csrf_exempt().

Topic guide Security in Django

CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent. Django has built-in protection against most types of CSRF attacks, providing you have enabled and used it where appropriate.

Reference Cross Site Request Forgery protection

The CSRF protection cannot protect against man-in-the-middle attacks, so use HTTPS with HTTP Strict Transport Security.