While I think Adam's right that adding one or two new settings wouldn't be a problem, I do worry about the ongoing proliferation, and it's a thing that I keep wanting to try to find the time to work on but never actually succeed at.
Separate from the suggestion of a generic way to add headers on every response, I've been leaning for a while toward the idea of consolidating the security-header settings the way we've already consolidated database and template settings. We can paint the bikeshed whatever color, but suppose for sake of an example name we add a SECURITY_HEADERS setting, with each one configured under its own key. That would allow X-Frame-Options, content sniffing, HSTS, Referrer-Policy, opener policy, and future stuff like CSP, built-in CORS, etc. to all be defined in a single place that doesn't proliferate a huge number of new settings, or require adding and supporting a new setting every time a new one comes along (which, with security headers, is about twice a week these days). For now I think the best thing would be to accept the opener-policy work as-is, then get consensus around a proposal for how future security headers should be handled. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%40mail.gmail.com.
