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 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,**defaults) : 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.

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

Reference System check framework Core system checks

This check appeared in Django 3.1 and 3.2. 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.

Reference

Applications System check framework Built-in class-based views API Clickjacking Protection contrib packages 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 Paginator Request and …

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.

How-to

… Reference. However, these guides will help you quickly accomplish common tasks. How to authenticate using REMOTE_USER How to use Django’s CSRF protection How to create custom django-admin commands How to create custom model fields How to write custom lookups How …

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

… as needed. Severity levels are: High: Remote code execution SQL injection Moderate: Cross site scripting (XSS) Cross site request forgery (CSRF) Denial-of-service attacks Broken authentication Low: 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.

Topic guide Writing views

The page_not_found() view is overridden by handler404: The server_error() view is overridden by handler500: The permission_denied() view is overridden by handler403: The bad_request() view is overridden by handler400: NOTE: Use the CSRF_FAILURE_VIEW setting to override the CSRF error > view.