The CSRF middleware and template tag provides easy-to-use protection against\nCross Site Request Forgeries. This type of attack occurs when a malicious\nwebsite contains a link, a form button or some JavaScript that is intended to\nperform some action on your website, using the credentials of a logged-in user\nwho visits the malicious site in their browser. A related type of attack,\n“login CSRF”, where an attacking site tricks a user’s browser into logging into\na site with someone else’s credentials, is also covered.
\nThe first defense against CSRF attacks is to ensure that GET requests (and\nother “safe” methods, as defined by RFC 9110 Section 9.2.1) are side effect\nfree. Requests via “unsafe” methods, such as POST, PUT, and DELETE, can then be\nprotected by the steps outlined in Come usare la protezione CSRF di Django.
\nThe CSRF protection is based on the following things:
\nA CSRF cookie that is a random secret value, which other sites will not have\naccess to.
\nCsrfViewMiddleware sends this cookie with the response whenever\ndjango.middleware.csrf.get_token() is called. It can also send it in\nother cases. For security reasons, the value of the secret is changed each\ntime a user logs in.
A hidden form field with the name “csrfmiddlewaretoken”, present in all\noutgoing POST forms.
\nIn order to protect against BREACH attacks, the value of this field is\nnot simply the secret. It is scrambled differently with each response using\na mask. The mask is generated randomly on every call to get_token(), so\nthe form field value is different each time.
This part is done by the csrf_token template tag.
For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or\nTRACE, a CSRF cookie must be present, and the “csrfmiddlewaretoken” field\nmust be present and correct. If it isn’t, the user will get a 403 error.
\nWhen validating the “csrfmiddlewaretoken” field value, only the secret,\nnot the full token, is compared with the secret in the cookie value.\nThis allows the use of ever-changing tokens. While each request may use its\nown token, the secret remains common to all.
\nThis check is done by CsrfViewMiddleware.
CsrfViewMiddleware verifies the Origin header, if provided by the\nbrowser, against the current host and the CSRF_TRUSTED_ORIGINS\nsetting. This provides protection against cross-subdomain attacks.
In addition, for HTTPS requests, if the Origin header isn’t provided,\nCsrfViewMiddleware performs strict referer checking. This means that\neven if a subdomain can set or modify cookies on your domain, it can’t force\na user to post to your application since that request won’t come from your\nown exact domain.
This also addresses a man-in-the-middle attack that’s possible under HTTPS\nwhen using a session independent secret, due to the fact that HTTP\nSet-Cookie headers are (unfortunately) accepted by clients even when\nthey are talking to a site under HTTPS. (Referer checking is not done for\nHTTP requests because the presence of the Referer header isn’t reliable\nenough under HTTP.)
If the CSRF_COOKIE_DOMAIN setting is set, the referer is compared\nagainst it. You can allow cross-subdomain requests by including a leading\ndot. For example, CSRF_COOKIE_DOMAIN = '.example.com' will allow POST\nrequests from www.example.com and api.example.com. If the setting is\nnot set, then the referer must match the HTTP Host header.
Expanding the accepted referers beyond the current host or cookie domain can\nbe done with the CSRF_TRUSTED_ORIGINS setting.
This ensures that only forms that have originated from trusted domains can be\nused to POST data back.
\nIt deliberately ignores GET requests (and other requests that are defined as\n“safe” by RFC 9110 Section 9.2.1). These requests ought never to have any\npotentially dangerous side effects, and so a CSRF attack with a GET request\nought to be harmless. RFC 9110 Section 9.2.1 defines POST, PUT, and DELETE\nas “unsafe”, and all other methods are also assumed to be unsafe, for maximum\nprotection.
\nThe CSRF protection cannot protect against man-in-the-middle attacks, so use\nHTTPS with\nHTTP Strict Transport Security. It also assumes validation of\nthe HOST header and that there aren’t any\ncross-site scripting vulnerabilities on your site\n(because XSS vulnerabilities already let an attacker do anything a CSRF\nvulnerability allows and much worse).
\n\nSubdomains within a site will be able to set cookies on the client for the\nwhole domain. By setting the cookie and using a corresponding token, subdomains\nwill be able to circumvent the CSRF protection. The only way to avoid this is\nto ensure that subdomains are controlled by trusted users (or, are at least\nunable to set cookies). Note that even without CSRF, there are other\nvulnerabilities, such as session fixation, that make giving subdomains to\nuntrusted parties a bad idea, and these vulnerabilities cannot easily be fixed\nwith current browsers.
\nThe examples below assume you are using function-based views. If you\nare working with class-based views, you can refer to Decorating\nclass-based views.
\nThis decorator marks a view as being exempt from the protection ensured by\nthe middleware. Example:
\nfrom django.http import HttpResponse\nfrom django.views.decorators.csrf import csrf_exempt\n\n\n@csrf_exempt\ndef my_view(request):\n return HttpResponse("Hello world")\nDecorator that provides the protection of\nCsrfViewMiddleware to a view.
Usage:
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@csrf_protect\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nNormally the csrf_token template tag will not work if\nCsrfViewMiddleware.process_view or an equivalent like csrf_protect\nhas not run. The view decorator requires_csrf_token can be used to\nensure the template tag does work. This decorator works similarly to\ncsrf_protect, but never rejects an incoming request.
Example:
\nfrom django.shortcuts import render\nfrom django.views.decorators.csrf import requires_csrf_token\n\n\n@requires_csrf_token\ndef my_view(request):\n c = {}\n # ...\n return render(request, "a_template.html", c)\nThis decorator forces a view to send the CSRF cookie.
\nA number of settings can be used to control Django’s CSRF behavior:
\n\nNo, this is by design. Not linking CSRF protection to a session allows using\nthe protection on sites such as a pastebin that allow submissions from\nanonymous users which don’t have a session.
\nIf you wish to store the CSRF token in the user’s session, use the\nCSRF_USE_SESSIONS setting.
For security reasons, CSRF tokens are rotated each time a user logs in. Any\npage with a form generated before a login will have an old, invalid CSRF token\nand need to be reloaded. This might happen if a user uses the back button after\na login or if they log in a different browser tab.
\n