Content Security Policy
Referrer-Policy
Subresource integrity
CORS
rel="noopener"
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 anydependencies in setup.py, and warn if known-insecure versions arespecified.
As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues.
I'd really like to see easy integration for report only mode
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
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
--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-develop...@googlegroups.com.To post to this group, send email to django-d...@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/a31b7f78-2e13-4190-aa58-9db2f00ac909%40googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.