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.