The proposal seems to be a setting of the form:
SECURITY_HEADERS = {
'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
...
}
Currently we have system checks to suggest
setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision
trying to keep these checks? It seems it'll be more complicated to parse
and validate arbitrary string values instead of individual settings.
It seems some headers may still need special handling in
SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if
request.is_secure().
On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. Would
> love to get CORS into core too.
>
> The Opener-Policy ticket has been marked as someday/maybe because the
> header is still not widely supported.
>
> On Thu, 20 Aug 2020 at 00:02, James Bennett <ubern...@gmail.com> wrote:
>
>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%40mail.gmail.com
>> .
>>
>
>
> --
> Adam
>
--
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/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com.
