On Friday, March 26, 2021 at 1:16:30 AM UTC-7 Adam Johnson wrote:
> That would be counter to how all current dict based settings work, so I
> think it would be too surprising.
>
I see. The django.conf.settings object should only include the raw settings
data and not auxiliary objects that can depend on that data. In that case,
my suggestion can be taken as an alternative API to a
"get_security_header()" function. It can be an dict-like object imported
from a module as opposed to being accessed through django.conf.settings.
One advantage of a dict-like object over a single function is that has the
ability to grow helper methods over time in addition to the dict-like
accesses. That could be useful in different contexts. A precedent for this
is the django.db.connections object, which is a ConnectionHandler object
constructed from settings and that supports some dict-like operations.
--Chris
>
> On Fri, 26 Mar 2021 at 05:35, chris.j...@gmail.com <chris.j...@gmail.com>
> wrote:
>
>> I just came across this thread after seeing a related PR. Rather than a
>> "get_security_header()" function, couldn't Django make the setting an
>> object that is accessed by the user like a dict, but internally (underneath
>> the hood) it tries from a user-defined dict and then falls back to a value
>> in a Django-defined dict of defaults?
>>
>> --Chris
>>
>>
>> On Sunday, January 24, 2021 at 1:08:24 PM UTC-8 timog...@gmail.com wrote:
>>
>>> If we go with something like:
>>>
>>> SECURITY_HEADERS = {
>>> "REFERRER_POLICY": "same-origin",
>>> "HSTS": {
>>> "PRELOAD": True,
>>> "SECONDS": 1_000_000,
>>> },
>>> }
>>>
>>> should we have an empty dictionary as the default or a dictionary with
>>> defaults for all settings?
>>>
>>> A drawback of an empty dictionary is that any code that wants to
>>> retrieve a setting has to do something like
>>> settings.SECURITY_HEADERS.get('REFERRER_POLICY', '<fallback value>') which
>>> means the fallback value is duplicated every place the setting is
>>> consulted. Maybe a way to mitigate that is to add a
>>> "get_security_header()" function that retrieves from django.conf.settings
>>> (user-defined settings) and falls back to some defaults.
>>>
>>> A drawback of a fully-populated default is that overriding it either
>>> requires users to redefine the entire dictionary or writing code like:
>>>
>>> from django.conf.global_settings import SECURITY_HEADERS
>>> SECURITY_HEADERS['REFERRER_POLICY'] = '...'
>>>
>>> If users redefine the entire dictionary, then adding new
>>> SECURITY_HEADERS options in future Django versions will require something
>>> like "get_security_header()" since we won't be able to assume the key is
>>> there in projects upgrading from older versions.
>>>
>>> I'm not so sure the benefit of consolidating to a single setting is
>>> worth this additional complexity.
>>> On Tuesday, January 19, 2021 at 8:27:58 AM UTC-5 Adam Johnson wrote:
>>>
>>>> I don't see the need for adding a setting to add headers to outgoing
>>>> responses. A middleware to do so is a handful of lines:
>>>>
>>>> class SecurityHeadersMiddleware:
>>>> def __init__(self, get_response):
>>>> self.get_response = get_response
>>>>
>>>> def __call__(self, request):
>>>> response = self.get_response(request)
>>>> response["Cross-Origin-Embedder-Policy"] = "require-corp"
>>>> return response
>>>>
>>>> Also there are many non-security related headers one might want to add,
>>>> so having the ability to add them in a setting called SECURITY_HEADERS
>>>> could be confusing for maintenance.
>>>>
>>>> On Tue, 19 Jan 2021 at 12:02, Tim Graham <timog...@gmail.com> wrote:
>>>>
>>>>> I guess there have been a few different proposals here, but I imagined
>>>>> SECURITY_HEADERS would allow setting any security-related header without
>>>>> making changes in Django. If the setting is more than header/value pairs,
>>>>> then it seems this won't be the case.
>>>>>
>>>>> On Tuesday, January 19, 2021 at 4:39:54 AM UTC-5 Adam Johnson wrote:
>>>>>
>>>>>> I'd imagined the setting would be more like a roll-up of the existing
>>>>>> settings, so no need for parsing:
>>>>>>
>>>>>> SECURITY_HEADERS = {
>>>>>> "REFERRER_POLICY": "same-origin",
>>>>>> "HSTS": {
>>>>>> "PRELOAD": True,
>>>>>> "SECONDS": 1_000_000,
>>>>>> },
>>>>>> }
>>>>>>
>>>>>>
>>>>>> On Tue, 19 Jan 2021 at 01:30, Tim Graham <timog...@gmail.com> wrote:
>>>>>>
>>>>>>> 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-develop...@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
>>>>>>>
>>>>>>> <https://groups.google.com/d/msgid/django-developers/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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-develop...@googlegroups.com.
>>>>>
>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/3ae8a31f-a53a-4415-8e51-6ce3faee85a1n%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/django-developers/3ae8a31f-a53a-4415-8e51-6ce3faee85a1n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/ad7f2050-a28d-44ca-a6ba-dcc9405f93d0n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/ad7f2050-a28d-44ca-a6ba-dcc9405f93d0n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/5342a3eb-95d1-4284-973e-0dfc6867e28an%40googlegroups.com.
