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 setup.py, and warn if known-insecure versions are
specified.


Improved security documentation
---------------------------------------------

Right now we have OK documentation on security, in that we have an
overview[9] listing the broad categories of things Django can protect
you against and pointing to their documentation.

I'd like to expand on that by including a rundown of where to learn
about common security issues, how to go beyond the basic protective
mechanisms Django includes today, and automated scanning/security
check tools like securityheaders, Mozilla Observatory, pyup,
requires.io, etc.


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[2] https://pypi.org/project/django_csp/
[3]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
[4] https://pypi.org/project/django-referrer-policy/
[5]
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[6] https://pypi.org/project/django-cors-headers/
[7] https://mathiasbynens.github.io/rel-noopener/
[8] https://pypi.org/project/safety/
[9] https://docs.djangoproject.com/en/2.0/topics/security/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-9TVC33NjcBwOg9%2B1hd-99kwJ6HiLzuWQV-y1UhBybkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to