From 6bb01b0b3cc6e5b2cf8d75ed2fd00a442d5caf52 Mon Sep 17 00:00:00 2001
From: Alasdair Nicol <alasdair@thenicols.net>
Date: Thu, 19 Jan 2017 20:56:39 +0000
Subject: [PATCH] [1.11.x] Refs #16859 -- Updated CSRF FAQ to mention
 CSRF_USE_SESSIONS setting.

Backport of 503e944ac792498e7b38c799d8e4b06f74e9d65a from master
---
 docs/ref/csrf.txt | 7 +++++--
 1 file 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?
 ----------------------------------------------------------------------