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.

Reference Settings Core Settings

New in Django 4.1. Default: False Whether to mask the CSRF cookie. See release notes for usage details. WARNING: Deprecated since version 4.1: This transitional setting is deprecated and will be removed in Django 5.0.

4.2

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.

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

A view needs CSRF protection under one set of conditions only, and mustn’t have it for the rest of the time. Solution: use csrf_exempt() for the whole view function, and csrf_protect() for the path within it that needs protection. Example:

Reference

The CSRF middleware and template tag provides easy-to-use protection against Cross Site Request Forgeries.

Reference Settings Core Settings Topical Index

Cross Site Request Forgery Protection CSRF_COOKIE_DOMAIN CSRF_COOKIE_NAME CSRF_COOKIE_PATH CSRF_COOKIE_SAMESITE CSRF_COOKIE_SECURE CSRF_FAILURE_VIEW CSRF_HEADER_NAME CSRF_TRUSTED_ORIGINS CSRF_USE_SESSIONS SECRET_KEY SECRET_KEY_FALLBACKS URLIZE_ASSUME_HTTPS X_FRAME_OPTIONS

Topic guide Security in Django

Similar to the CSRF limitations requiring a site to be deployed such that untrusted users don’t have access to any subdomains, django.contrib.sessions also has limitations. See the session topic guide section on security for details.

Reference Cross Site Request Forgery protection

A number of settings can be used to control Django’s CSRF behavior: CSRF_COOKIE_AGE CSRF_COOKIE_DOMAIN CSRF_COOKIE_HTTPONLY CSRF_COOKIE_NAME CSRF_COOKIE_PATH CSRF_COOKIE_SAMESITE CSRF_COOKIE_SECURE CSRF_FAILURE_VIEW CSRF_HEADER_NAME CSRF_TRUSTED_ORIGINS CSRF_USE_SESSIONS

Topic guide Testing tools The test client

Use the django.test.Client class to make requests. classClient(enforce_csrf_checks=False,raise_request_exception=True,json_encoder=DjangoJSONEncoder,*,headers=None,query_params=None,**defaults)[source] : A testing HTTP client. Takes several arguments that can customize behavior.

How-to How-to guides

How to authenticate using REMOTE_USER How to use Django’s Content Security Policy How to use Django’s CSRF protection How to write a custom storage class How to create custom django-admin commands How to customize the shell command NOTE: The Django …

5.1 5.2 6.0 dev

How-to Deployment checklist Environment-specific settings

This setting is required to protect your site against some CSRF attacks. If you use a wildcard, you must perform your own validation of the Host HTTP header, or otherwise ensure that you aren’t vulnerable to this category of attacks.

Django documentation

Security is a topic of paramount importance in the development of web applications and Django provides multiple protection tools and mechanisms: Security overview Disclosed security issues in Django Clickjacking protection Cross Site Request Forgery protection Cryptographic signing Security Middleware Content …

Reference

Applications System check framework Built-in class-based views API Clickjacking Protection contrib packages Content Security Policy Cross Site Request Forgery protection Databases django-admin and manage.py Running management commands from your code Django Exceptions File handling Forms Logging Middleware Migration Operations Models …

Reference Settings Sessions

To use cross-domain cookies with CSRF_USE_SESSIONS, you must include a leading dot (e.g. ".example.com") to accommodate the CSRF middleware’s referer checking. Be cautious when updating this setting on a production site.

Reference Settings Sessions

Default: 'Lax' The value of the SameSite flag on the session cookie. This flag prevents the cookie from being sent in cross-site requests thus preventing CSRF attacks and making some methods of stealing session cookie impossible.

Internals Django’s security policies

… individual vulnerabilities. Severity levels are: High Remote code execution SQL injection Moderate Cross site scripting (XSS) Cross site request forgery (CSRF) Broken authentication Low Denial-of-service attacks Sensitive data exposure Broken session management Unvalidated redirects/forwards Issues requiring an uncommon configuration option …

5.1 5.2 6.0 dev

Reference System check framework Core system checks

This was likely an oversight when migrating from url() to path(). 4_0.E001: As of Django 4.0, the values in the CSRF_TRUSTED_ORIGINS setting must start with a scheme (usually http:// or https://) but found <hostname>.

Reference Request and response objects FileResponse objects

HttpResponse.set_signed_cookie(key,value,salt='',max_age=None,expires=None,path='/',domain=None,secure=False,httponly=False,samesite=None) : Like set_cookie(), but cryptographic signing the cookie before setting it. Use in conjunction with HttpRequest.get_signed_cookie().