How-to How to use Django’s CSRF protection

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

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

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 Deployment checklist

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.

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 Migrating email to …

Reference System check framework

security.E101: The CSRF failure view 'path.to.view' does not take the correct number of arguments. security.E102: The CSRF failure view 'path.to.view' could not be imported. security.E026: The CSP setting <SETTING_NAME> must be a dictionary (got <value> instead).

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

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

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.

Django documentation

A key concern in Django’s design philosophy is to make it easier to build applications that work safely and efficiently, in the real world.

Internals Django Deprecation Timeline

The csrf_response_exempt and csrf_view_exempt decorators will be removed. Since 1.4 csrf_response_exempt has been a no-op (it returns the same function), and csrf_view_exempt has been a synonym for django.views.decorators.csrf.csrf_exempt, which should be used to replace it.

Internals Django’s security policy

… 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 …

Reference System check framework

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 Cross Site Request Forgery protection

Due to the CSRF > protection’s strict referer checking on HTTPS requests, those techniques > cause a CSRF failure on requests with ‘unsafe’ methods. Instead, use > alternatives like <a rel="noreferrer" ...>" for links to third-party > sites.

Reference Request and response 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().

Reference Settings

By default, is_secure() determines if a request is secure by confirming that a requested URL uses https://. This method is important for Django’s CSRF protection, and it may be used by your own code or third-party apps.

Reference The Django template language: for Python programmers

In the default generated settings file, the default template engine contains the following context processors: In addition to these, RequestContext always enables 'django.template.context_processors.csrf'.