I think there is certainly a strong case based on "secure by default" to include this in core, where it would otherwise face the "it works fine as a 3rd party app" barrier to entry.
IMHO it would require, however, that the solutions be sufficiently generic as to not enforce an overly restrictive world view. I, for one, would be very interested to see more details here on what changes you propose. Then, at least, we can keep a mailing-list history record of the discussion. -- Curtis On Tue, 16 Jul 2019, at 12:22, Jonathon Sumner wrote: > Hi all, > > Sorry for jumping in on an old thread, but I stumbled across James' post > after writing a similar wish list. Securityheaders.com (and the Mozilla > http-observatory) score an out-of-the-box Django site fairly harshly. With > that in mind, me and a colleague put together a very simple package > (django-security-headers) to add some headers, package django-csp, self-test > against a local http-observatory instance (using django-sslserver), and > provide default settings to get a better score. > > I completely agree with Jacob that adding CSP *post facto* can be a > minefield, but I think it would promote better practices if Django shipped > with secure defaults for CSP, referrer policy, etc. and required the user to > turn these settings off for their application. > > Anyway, although I would be a newbie contributor, I would be more than happy > to pick up the thread started by James if the senior Django community sees > value in it! > > Cheers, > Jonathon > > > > On Tuesday, May 1, 2018 at 11:13:17 AM UTC-4, Jacob Kaplan-Moss wrote: >> Great ideas, James. I totally agree we shouldn't rest on our laurels, and >> love the goal of pushing things forwards. Overall, I'm not sure a DEP is >> needed: each of these things is fairly small and tightly scoped, can be >> implemented on its own, and provides value independent of the whole. That >> seems like a scenario where just a bunch of loosely-related PRs makes the >> most sense. Added bonus: many of these things would be fairly easy pickings >> for a new contributor. If you wanted, you could delegate/coordinate some of >> this, and help us get more folks involved as a bonus. >> >> Some comments on specifics: >> >> On Tue, May 1, 2018 at 12:28 AM, James Bennett <[email protected]> wrote: >>> Content Security Policy >> >> CSP is a tricky one. On the one hand, it's a tremendously effective defense >> against XSS. But, it's pretty tricky to get right: I've seen several sites >> struggle with a proper CSP config for years. It tends to be beyond the grasp >> of your classic one- or two-person dev team. When you get it wrong, it >> totally hoses your site. >> >> Most complex sites find they need to operate in report-only mode for a while >> and analyze the data before switching to enforce. And that requires a good >> reporting/analysis mechanism (something like report-uri.com, or a local >> equivalent). >> So all that to say: I highly support exploring this more, but it could be >> easy to turn CSP into a foot-gun. I don't think it's as easy as just >> shipping django-csp and calling it a day; we'd need to make sure it's not >> going to cause more problems than it solves. >> >>> Referrer-Policy >> >> +1, this seems like a no-brainer. >> >>> >>> Subresource integrity >> >> The jury seems to still be out on the value of SRI (at least, in my corner >> of the security community). It has some serious problems with dynamic >> assets, and with externally-hosted tools like Google Analytics. I'm not >> convinced that the current spec is fully-baked enough for us to support. >> The admin's a special case since we tightly control what's shipped there; >> SRI-for-the-admin would be a nice, if incremental improvement. Preventing >> injection attacks in the admin is a very good thing :) >> >>> >>> CORS >> >> Yup, another no-brainer. >> >>> rel="noopener" >> >> I'm not sure I get this one, might need to see what you come up with to >> understand the effect. >> >>> 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. >> >> This seems entirely doable! Of course, grappling with the various options >> for dependency management might make this.. less fun >> (https://xkcd.com/1987/). >> >> Jacob > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/a31b7f78-2e13-4190-aa58-9db2f00ac909%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/a31b7f78-2e13-4190-aa58-9db2f00ac909%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/dd3f66b2-e988-43f8-91c3-62f7d8a020f7%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
