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.
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>
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>
* 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>