Hey James,
I think these ideas are fantastic.
I used EmberJS for a project and the development server contained a built
in CSP report URL which just printed what the browser sent to the console.
This was very useful during development as you could immediately see CSP
errors that were triggered rather than perhaps having to navigate to
another page and seeing the issues without context. It would be great if we
could add this functionality to Django, perhaps even in production - if we
provided a route that would output CSP errors to a specified logger users
could configure the logger to send the errors to a variety of places
without too much configuration or complexity?
The rel=noopener would be pretty hard to implement IMO, and while noble I’m
not sure how we could even do this (outside of the Django admin)?
I don’t have much else to add, other than I’d love to help with the
implementation of any of these if I’m able.
Tom
On 1 May 2018 at 08:28:18, James Bennett (ubernost...@gmail.com) wrote:
I've written this up in pseudo-DEP format partly for ease of
organization, and partly because I'm unsure whether it would require a
DEP. Right now I'm just throwing it out here as a proposal, and
offering to work on implementing it; if you have questions, concerns,
or suggestions for things to add to it, please let me know :)
Introduction
-
Django has acquired a reputation for being helpful with/good at
"security". Which has been a focus since at least 1.0; Django goes out
of its way to protect you out of the box against common security
problems, and includes a lot of tools geared toward making it easy to
do the right thing when building apps.
But security is a Red Queen problem; we can't ever pause and rest,
since as soon as we do we'll fall behind.
In light of which, I'd like to propose a few security-related
improvements/additions, and offer to put in the time to help implement
them. My baseline goal here is to set things up such that it's
possible, using only things that ship with Django itself and an
SSL-enabled hosting service, to score an A+ rating on
securityheaders.com. Beyond that, some stretch goals are possible.
Content Security Policy
CSP[1] is one of the more important defenses available against XSS and
a few other types of attacks. Django does not currently have
out-of-the-box support for it; the usual solution is to install
django-csp[2], configure it and set up its middlware to emit the CSP
header.
I'd like to see support for CSP built in to Django. This could be done
by integrating django-csp, which is open source and uses a compatible
license, though there'd need to be some updates to its documentation
(which seems to lag a bit behind what the code supports) and it might
also be good to switch over to using dictionary-based configuration.
Referrer-Policy
-
The Referrer-Policy header[3] is relatively new, but gaining support
in major browsers. It helps enhance both security and privacy.
I wrote a package earlier this year[4] that supports sending the
Referrer-Policy header, and BSD-licensed it. It would be relatively
easy to integrate this into Django.
Subresource integrity
-
Subresource integrity[5] allows the author of an HTML document to
supply the expected hashes of resources (scripts, stylesheets, images,
etc.) referenced in the document. This helps to harden against not
only local breaches, but also breaches of third-party scripts and
CDNs.
I don't have a clear vision yet of how it would work, but I'd like to
see the form media system and the staticfiles app grow support for
SRI. In the case of form media, the output already generates the full
HTML and could include the hash. In the case of the {% static %}
template tag, I'm open to suggestions for how it could
generate/include the hash. The admin should use this by default.
CORS
-
Cross-Origin Resource Sharing is increasingly important on the modern
web, and Django does not currently support setting CORS headers. There
is an open-source package for CORS in Django[6], which could be
integrated.
rel="noopener"
-
Setting rel="noopener" on links which will open in new tabs/windows is
an easy way to head off certain types of surprising attacks[7]. Like
SRI, I don't yet have a great plan for how this could be supported
easily/automatically in Django, but I'd like to give it a try.
Improved system-check integration
---
Currently the security system-check is OK, but still a bit
minimal. I'd like to add support for checking at least everything I've
proposed adding above, and probably several more items. In my ideal
world, a service like securityheaders.com could be replicated by the
security check.
In my magical stretch-goal land, I'd also figure out a way to support
the pyup safety library[8] to scan for a requirements file and any
dependencies in se
