summaryrefslogtreecommitdiff
path: root/docs/ref
diff options
context:
space:
mode:
Diffstat (limited to 'docs/ref')
-rw-r--r--docs/ref/csrf.txt7
1 files changed, 5 insertions, 2 deletions
diff --git a/docs/ref/csrf.txt b/docs/ref/csrf.txt
index 3d1ecc1237..a95bc2af60 100644
--- a/docs/ref/csrf.txt
+++ b/docs/ref/csrf.txt
@@ -532,13 +532,16 @@ Some security audit tools flag this as a problem but as mentioned before, an
attacker cannot steal a user's browser's CSRF cookie. "Stealing" or modifying
*your own* token using Firebug, Chrome dev tools, etc. isn't a vulnerability.
-Is the fact that Django's CSRF protection isn't linked to a session a problem?
-------------------------------------------------------------------------------
+Is it a problem that Django's CSRF protection isn't linked to a session by default?
+-----------------------------------------------------------------------------------
No, this is by design. Not linking CSRF protection to a session allows using
the protection on sites such as a `pastebin` that allow submissions from
anonymous users which don't have a session.
+If you wish to store the CSRF token in the user's session, use the
+:setting:`CSRF_USE_SESSIONS` setting.
+
Why might a user encounter a CSRF validation failure after logging in?
----------------------------------------------------------------------