Fixed #27863 -- Added support for the SameSite cookie flag.

Thanks Alex Gaynor for contributing to the patch.

docs/ref/csrf.txt

@@ -513,6 +513,7 @@ A number of settings can be used to control Django's CSRF behavior:
 * :setting:`CSRF_COOKIE_HTTPONLY`
 * :setting:`CSRF_COOKIE_NAME`
 * :setting:`CSRF_COOKIE_PATH`
+* :setting:`CSRF_COOKIE_SAMESITE`
 * :setting:`CSRF_COOKIE_SECURE`
 * :setting:`CSRF_FAILURE_VIEW`
 * :setting:`CSRF_HEADER_NAME`

docs/ref/request-response.txt

@@ -748,7 +748,7 @@ Methods
 
     Sets a header unless it has already been set.
 
-.. method:: HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)
+.. method:: HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False, samesite=None)
 
     Sets a cookie. The parameters are the same as in the
     :class:`~http.cookies.Morsel` cookie object in the Python standard library.
@@ -773,8 +773,17 @@ Methods
       when it is honored, it can be a useful way to mitigate the
       risk of a client-side script from accessing the protected cookie
       data.
+    * Use ``samesite='Strict'`` or ``samesite='Lax'`` to tell the browser not
+      to send this cookie when performing a cross-origin request. `SameSite`_
+      isn't supported by all browsers, so it's not a replacement for Django's
+      CSRF protection, but rather a defense in depth measure.
+
+    .. versionchanged:: 2.1
+
+        The ``samesite`` argument was added.
 
     .. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
+    .. _SameSite: https://www.owasp.org/index.php/SameSite
 
     .. warning::
 
@@ -784,7 +793,7 @@ Methods
         to store a cookie of more than 4096 bytes, but many browsers will not
         set the cookie correctly.
 
-.. method:: HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True)
+.. method:: HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True, samesite=None)
 
     Like :meth:`~HttpResponse.set_cookie()`, but
     :doc:`cryptographic signing </topics/signing>` the cookie before setting

docs/ref/settings.txt

@@ -365,6 +365,20 @@ This is useful if you have multiple Django instances running under the same
 hostname. They can use different cookie paths, and each instance will only see
 its own CSRF cookie.
 
+.. setting:: CSRF_COOKIE_SAMESITE
+
+``CSRF_COOKIE_SAMESITE``
+------------------------
+
+.. versionadded:: 2.1
+
+Default: ``'Lax'``
+
+The value of the `SameSite`_ flag on the CSRF cookie. This flag prevents the
+cookie from being sent in cross-site requests.
+
+See :setting:`SESSION_COOKIE_SAMESITE` for details about ``SameSite``.
+
 .. setting:: CSRF_COOKIE_SECURE
 
 ``CSRF_COOKIE_SECURE``
@@ -3025,6 +3039,44 @@ This is useful if you have multiple Django instances running under the same
 hostname. They can use different cookie paths, and each instance will only see
 its own session cookie.
 
+.. setting:: SESSION_COOKIE_SAMESITE
+
+``SESSION_COOKIE_SAMESITE``
+---------------------------
+
+.. versionadded:: 2.1
+
+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.
+
+Possible values for the setting are:
+
+* ``'Strict'``: prevents the cookie from being sent by the browser to the
+  target site in all cross-site browsing context, even when following a regular
+  link.
+
+  For example, for a GitHub-like website this would mean that if a logged-in
+  user follows a link to a private GitHub project posted on a corporate
+  discussion forum or email, GitHub will not receive the session cookie and the
+  user won't be able to access the project. A bank website, however, most
+  likely doesn't want to allow any transactional pages to be linked from
+  external sites so the ``'Strict'`` flag would be appropriate.
+
+* ``'Lax'`` (default): provides a balance between security and usability for
+  websites that want to maintain user's logged-in session after the user
+  arrives from an external link.
+
+  In the GitHub scenario, the session cookie would be allowed when following a
+  regular link from an external website and be blocked in CSRF-prone request
+  methods (e.g. ``POST``).
+
+* ``None``: disables the flag.
+
+.. _SameSite: https://www.owasp.org/index.php/SameSite
+
 .. setting:: SESSION_COOKIE_SECURE
 
 ``SESSION_COOKIE_SECURE``
@@ -3425,6 +3477,7 @@ Security
   * :setting:`CSRF_COOKIE_DOMAIN`
   * :setting:`CSRF_COOKIE_NAME`
   * :setting:`CSRF_COOKIE_PATH`
+  * :setting:`CSRF_COOKIE_SAMESITE`
   * :setting:`CSRF_COOKIE_SECURE`
   * :setting:`CSRF_FAILURE_VIEW`
   * :setting:`CSRF_HEADER_NAME`

docs/releases/2.1.txt

@@ -112,7 +112,8 @@ Minor features
 :mod:`django.contrib.sessions`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* ...
+* Added the :setting:`SESSION_COOKIE_SAMESITE` setting to set the ``SameSite``
+  cookie flag on session cookies.
 
 :mod:`django.contrib.sitemaps`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -143,7 +144,8 @@ Cache
 CSRF
 ~~~~
 
-* ...
+* Added the :setting:`CSRF_COOKIE_SAMESITE` setting to set the ``SameSite``
+  cookie flag on CSRF cookies.
 
 Database backends
 ~~~~~~~~~~~~~~~~~
@@ -239,6 +241,9 @@ Requests and Responses
 
 * Added :meth:`.HttpRequest.get_full_path_info`.
 
+* Added the ``samesite`` argument to :meth:`.HttpResponse.set_cookie` to allow
+  setting the ``SameSite`` cookie flag.
+
 Serialization
 ~~~~~~~~~~~~~
 
@@ -338,6 +343,16 @@ variable now appears as an attribute of each option. For example, in a custom
 ``input_option.html`` template, change ``{% if wrap_label %}`` to
 ``{% if widget.wrap_label %}``.
 
+``SameSite`` cookies
+--------------------
+
+The cookies used for ``django.contrib.sessions``, ``django.contrib.messages``,
+and Django's CSRF protection now set the ``SameSite`` flag to ``Lax`` by
+default. Browsers that respect this flag won't send these cookies on
+cross-origin requests. If you rely on the old behavior, set the
+:setting:`SESSION_COOKIE_SAMESITE` and/or :setting:`CSRF_COOKIE_SAMESITE`
+setting to ``None``.
+
 Miscellaneous
 -------------
 

docs/topics/http/sessions.txt

@@ -629,6 +629,7 @@ behavior:
 * :setting:`SESSION_COOKIE_HTTPONLY`
 * :setting:`SESSION_COOKIE_NAME`
 * :setting:`SESSION_COOKIE_PATH`
+* :setting:`SESSION_COOKIE_SAMESITE`
 * :setting:`SESSION_COOKIE_SECURE`
 * :setting:`SESSION_ENGINE`
 * :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE`