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

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 …

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 System check framework Core system checks

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

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().

Reference Settings Core 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 Playing with Context objects

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'.

Topic guide Middleware

To activate a middleware component, add it to the MIDDLEWARE list in your Django settings. In MIDDLEWARE, each middleware component is represented by a string: the full Python path to the middleware factory’s class or function name.