Release notes
Django 4.1 release notes
Features deprecated in 4.1
CsrfViewMiddleware no longer masks the CSRF cookie like it does the CSRF token in the DOM. CsrfViewMiddleware now uses request.META['CSRF_COOKIE'] for storing the unmasked CSRF secret rather than a masked version. This is an undocumented, private API.
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.