From 65ac1431d5fa26154b619e4918b6b5464c21c3e0 Mon Sep 17 00:00:00 2001 From: Tomas McNamer Date: Mon, 14 Mar 2022 02:46:01 -0400 Subject: [PATCH] Refs #28592 -- Removed redundant spaces in docs/ref/csrf.txt. --- docs/ref/csrf.txt | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/ref/csrf.txt b/docs/ref/csrf.txt index dcd86c53ea9..8cbce28738b 100644 --- a/docs/ref/csrf.txt +++ b/docs/ref/csrf.txt @@ -6,10 +6,10 @@ Cross Site Request Forgery protection :synopsis: Protects against Cross Site Request Forgeries The CSRF middleware and template tag provides easy-to-use protection against -`Cross Site Request Forgeries`_. This type of attack occurs when a malicious +`Cross Site Request Forgeries`_. This type of attack occurs when a malicious website contains a link, a form button or some JavaScript that is intended to perform some action on your website, using the credentials of a logged-in user -who visits the malicious site in their browser. A related type of attack, +who visits the malicious site in their browser. A related type of attack, 'login CSRF', where an attacking site tricks a user's browser into logging into a site with someone else's credentials, is also covered. @@ -213,13 +213,13 @@ Rejected requests ================= By default, a '403 Forbidden' response is sent to the user if an incoming -request fails the checks performed by ``CsrfViewMiddleware``. This should +request fails the checks performed by ``CsrfViewMiddleware``. This should usually only be seen when there is a genuine Cross Site Request Forgery, or when, due to a programming error, the CSRF token has not been included with a POST form. The error page, however, is not very friendly, so you may want to provide your -own view for handling this condition. To do this, set the +own view for handling this condition. To do this, set the :setting:`CSRF_FAILURE_VIEW` setting. CSRF failures are logged as warnings to the :ref:`django.security.csrf @@ -359,9 +359,9 @@ Testing The ``CsrfViewMiddleware`` will usually be a big hindrance to testing view functions, due to the need for the CSRF token which must be sent with every POST -request. For this reason, Django's HTTP client for tests has been modified to +request. For this reason, Django's HTTP client for tests has been modified to set a flag on requests which relaxes the middleware and the ``csrf_protect`` -decorator so that they no longer rejects requests. In every other respect +decorator so that they no longer rejects requests. In every other respect (e.g. sending cookies etc.), they behave the same. If, for some reason, you *want* the test client to perform CSRF @@ -377,10 +377,10 @@ Limitations =========== Subdomains within a site will be able to set cookies on the client for the whole -domain. By setting the cookie and using a corresponding token, subdomains will -be able to circumvent the CSRF protection. The only way to avoid this is to +domain. By setting the cookie and using a corresponding token, subdomains will +be able to circumvent the CSRF protection. The only way to avoid this is to ensure that subdomains are controlled by trusted users (or, are at least unable -to set cookies). Note that even without CSRF, there are other vulnerabilities, +to set cookies). Note that even without CSRF, there are other vulnerabilities, such as session fixation, that make giving subdomains to untrusted parties a bad idea, and these vulnerabilities cannot easily be fixed with current browsers. @@ -503,7 +503,7 @@ Contrib and reusable apps Because it is possible for the developer to turn off the ``CsrfViewMiddleware``, all relevant views in contrib apps use the ``csrf_protect`` decorator to ensure -the security of these applications against CSRF. It is recommended that the +the security of these applications against CSRF. It is recommended that the developers of other reusable apps that want the same guarantees also use the ``csrf_protect`` decorator on their views.