[Django] #20825: Make cookies use the HTTPOnly flag by default

11 views
Skip to first unread message

Django

unread,
Jul 30, 2013, 12:43:41 AM7/30/13
to django-...@googlegroups.com
#20825: Make cookies use the HTTPOnly flag by default
-----------------------------------------+------------------------
Reporter: julien | Owner: julien
Type: New feature | Status: new
Component: HTTP handling | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
The `HttpOnly` cookie flag helps prevent the most common types of XSS
attacks (see https://www.owasp.org/index.php/HttpOnly). Thus it would be
preferable for Django to use it by default.

This change would be backwards-incompatible, in particular for
applications that rely on cookies being accessible from genuine client-
side Javascript code. Therefore this change should be clearly explained in
the release notes.

Some information about the benefits and caveats of using this flag should
also be added to the security section of the documentation.

This change is somewhat dependent on a resolution being found for #20755,
as the Python standard library's `cookies` module's management of
`HttpOnly` is inconsistent.

--
Ticket URL: <https://code.djangoproject.com/ticket/20825>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Feb 28, 2014, 7:02:12 AM2/28/14
to django-...@googlegroups.com
#20825: Make cookies use the HTTPOnly flag by default
-------------------------------+------------------------------------

Reporter: julien | Owner: julien
Type: New feature | Status: new
Component: HTTP handling | Version: 1.5
Severity: Normal | Resolution:

Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------

Comment (by erikr):

The current default for SESSION_COOKIE_HTTPONLY in current master is True.
So, this concerns only the CSRF cookie, and custom cookies set though
set_cookie() on a response. Are you referring to one of these
specifically, or both?

--
Ticket URL: <https://code.djangoproject.com/ticket/20825#comment:1>

Django

unread,
Jun 4, 2015, 11:37:45 AM6/4/15
to django-...@googlegroups.com
#20825: Make cookies use the HTTPOnly flag by default
-------------------------------+------------------------------------

Reporter: julien | Owner: julien
Type: New feature | Status: new
Component: HTTP handling | Version: 1.5
Severity: Normal | Resolution:

Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------

Comment (by raphaelm):

Actually, accessing the CSRF cookie via JavaScript is the recommended way
to use the CSRF protection with AJAX (see:
https://docs.djangoproject.com/en/1.8/ref/csrf/#ajax). So, as far as the
CSRF cookie is concerned, I'd close this as "wontfix".

As for set_cookie, this would break backwards compatibility and as the
most important cookie, the sessison cookie, is protected, I'd also vote
for wontfix here. Any other opinions?

--
Ticket URL: <https://code.djangoproject.com/ticket/20825#comment:2>

Django

unread,
Jun 4, 2015, 11:48:01 AM6/4/15
to django-...@googlegroups.com
#20825: Make cookies use the HTTPOnly flag by default
-------------------------------+------------------------------------
Reporter: julien | Owner: julien
Type: New feature | Status: closed

Component: HTTP handling | Version: 1.5
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Changes (by erikr):

* status: new => closed
* resolution: => wontfix


Comment:

I completely concur. For the `set_cookie` default, I do see a security
benefit, but I feel it's so small that it's not worth breaking the
backwards compatibility. Especially when considering that this is likely
to break things silently, and not be noticed in unit tests - only by vague
error reports from users.

--
Ticket URL: <https://code.djangoproject.com/ticket/20825#comment:3>

Reply all
Reply to author
Forward
0 new messages