Re: Rethink (?) how we handle security headers.

[chris.j...@gmail.com]

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  
> 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', '') 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  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  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 nee

Re: Rethink (?) how we handle security headers.

['Adam Johnson' via Django developers (Contributions to Django itself)]

That would be counter to how all current dict based settings work, so I
think it would be too surprising.

On Fri, 26 Mar 2021 at 05:35, 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', '') 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  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  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 
>>> 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, 

Re: Rethink (?) how we handle security headers.

[chris.j...@gmail.com]

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', '') 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  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  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  
>> 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 nam

Re: Rethink (?) how we handle security headers.

[Tim Graham]

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', '') 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  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  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  
> 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

Re: Rethink (?) how we handle security headers.

[Adam Johnson]

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  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  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  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
>>> 
>>> .
>>>
>>
>>
>> --
>> 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

Re: Rethink (?) how we handle security headers.

[Tim Graham]

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  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  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
>>  
>> 
>> .
>>
>
>
> -- 
> 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/3ae8a31f-a53a-4415-8e51-6ce3faee85a1n%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Adam Johnson]

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  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  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
> 
> .
>


-- 
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/CAMyDDM0enPLL%2BQq0SLUMde%2B5H6RxuMZr%2BG1TFL3NC_iD%3Dp4-sg%40mail.gmail.com.

Re: Rethink (?) how we handle security headers.

[Tim Graham]

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  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.

Re: Rethink (?) how we handle security headers.

[Adam Johnson]

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  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-developers+unsubscr...@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/CAMyDDM34YHpFGb7q0yJ_zjm-75r4Byhfoah8U30HnfQj8cUWSw%40mail.gmail.com.

Re: Rethink (?) how we handle security headers.

[James Bennett]

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.

Re: Rethink (?) how we handle security headers.

['Megan Huber' via Django developers (Contributions to Django itself)]

Hi Y'all, 

I suggested the addition of the COOP header. I don't have enough experience 
contributing to Django to know if the process of adding new headers should 
be streamlined. I am curious though if CORS or CORP support has ever been 
considered as a part of the security middleware. COOP is usually 
implemented with a header called Cross-origin Embedder Policy but it relies 
on CORS or CORP being set to a specific value. I know that currently Django 
projects use a middleware to handle CORS but we can't have a safe default 
for COEP set unless we know they are using this middleware. The middleware 
is also not a Mozilla repository. 

Maybe now is a good time to add support for CORS/CORP while we are adding 
many other security headers? I would be interested in contributing to this 
and could submit a new issue for it or do it as a part of the COOP ticket.

Another +1 to Adam's Add_Headers idea. This would be an effective way of 
keeping up with new security standards for concerned developers but would 
offer no protection to the average Django user.

Thanks,

Megan


On Friday, July 31, 2020 at 1:25:08 PM UTC-4 Adam Johnson wrote:

> > I would suggest that the redirection part be moved to a different 
> middleware.
>
> I doubt this would have any noticeable performance impact on any 
> application. I’d like to see profiling data before imposing such a change 
> on users.
>
> Also I find myself using the Django redirect with several different 
> “serverlwss” deployment setups.
>
> On Thu, 30 Jul 2020 at 17:43, Claude Paroz  wrote:
>
>> By the way, while reviewing the SecurityMiddleware, I would suggest that 
>> the redirection part be moved to a different middleware.
>> http to https redirection should preferably be done at the Web server 
>> level, and for those doing that properly, they still pay for the unneeded 
>> (albeit small) overhead of the `SecurityMiddleware.process_request`.
>>
>> > 3. For new headers I think we could add a setting called e.g. 
>> ADD_HEADERS - a dict of keys to values that 
>> > CommonMiddleware (or similar) could add to outgoing responses' headers. 
>>
>> +1 to that proposal.
>>
>> Claude
>>
>> -- 
>>
> 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/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.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/138e2004-49e2-4d70-a410-a53f4d80aa6an%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Adam Johnson]

> I would suggest that the redirection part be moved to a different
middleware.

I doubt this would have any noticeable performance impact on any
application. I’d like to see profiling data before imposing such a change
on users.

Also I find myself using the Django redirect with several different
“serverlwss” deployment setups.

On Thu, 30 Jul 2020 at 17:43, Claude Paroz  wrote:

> By the way, while reviewing the SecurityMiddleware, I would suggest that
> the redirection part be moved to a different middleware.
> http to https redirection should preferably be done at the Web server
> level, and for those doing that properly, they still pay for the unneeded
> (albeit small) overhead of the `SecurityMiddleware.process_request`.
>
> > 3. For new headers I think we could add a setting called e.g.
> ADD_HEADERS - a dict of keys to values that
> > CommonMiddleware (or similar) could add to outgoing responses' headers.
>
> +1 to that proposal.
>
> Claude
>
> --
> 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/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.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/CAMyDDM0SUWKZMSiUFsjrEUAkMx1Egdt2QV6T9RP%3DiqqNbqEdLw%40mail.gmail.com.

Re: Rethink (?) how we handle security headers.

[Claude Paroz]

By the way, while reviewing the SecurityMiddleware, I would suggest that 
the redirection part be moved to a different middleware.
http to https redirection should preferably be done at the Web server 
level, and for those doing that properly, they still pay for the unneeded 
(albeit small) overhead of the `SecurityMiddleware.process_request`.

> 3. For new headers I think we could add a setting called e.g. ADD_HEADERS 
- a dict of keys to values that 
> CommonMiddleware (or similar) could add to outgoing responses' headers. 

+1 to that proposal.

Claude

-- 
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/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.com.

Re: Rethink (?) how we handle security headers.

[Adam Johnson]

Sci - please stop posting on this mailing list about whatsapp etc. It's not
appropriate.

Carlton - I have three thoughts re: security headers

1. I'm fine adding new settings for them. I think it's basically part of
the territory. More headers are appearing, to support them we can use the
same mechanism users are familiar with. Most projects should be able to go
with the sensible default that Django provides.

2. On sensible defaults - the settings are currently bools but this
requires users to set them to False for development and True for deployment
on HTTPS. I think we could add a third value, 'on_https', that's the
default. It could be true based upon request.is_secure(). This would reduce
much of the user burden of these settings.

3. For new headers I think we could add a setting called e.g. ADD_HEADERS -
a dict of keys to values that CommonMiddleware (or similar) could add to
outgoing responses' headers. This would mean Django projects could use new
security headers before Django supports them. I think the settings versions
in SecurityMiddleware are still valuable since they provide defaults and
allow per-view customization where reasonable.

On Thu, 30 Jul 2020 at 10:08, Sci Mithilesh 
wrote:

> Your contact number send me I want a VIP site
>
> On Thu, 30 Jul 2020, 2:37 pm Carlton Gibson, 
> wrote:
>
>> Hi.
>>
>> (This is quite preliminary but...)
>>
>> So we added support for Referrer-Policy in 3.0
>> https://docs.djangoproject.com/en/3.0/ref/middleware/#referrer-policy
>>
>> This added the SECURE_REFERRER_POLICY setting.
>>
>> We have a Someday/Maybe Permissions-Policy (was Feature-Policy).
>> for https://code.djangoproject.com/ticket/30746
>>
>> Then a proposal for a new one Cross-Origin Opener Policy
>> https://code.djangoproject.com/ticket/31840
>>
>> > This can be implemented in a similar way to the Referrer-Policy header
>> in the security middleware.
>>
>> But are we going to continue to add settings along this line, one for
>> every new header that comes up?
>>
>> Maybe, but I feel like we might need to review how we handle such things.
>>
>>
>> One thought that has come up (here and elsewhere) is that it would be
>> good if Middleware could be configured with parameters without having to
>> subclass. I wonder if (I suspect) that has come up as an idea before?
>>
>>
>> Otherwise does anyone have thoughts on this issue? (Maybe we can just
>> keep adding settings — we have a lot for *_COOKIE_* for example.)
>>
>>
>> Thanks,
>> Carlton
>>
>> --
>> 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/f35d51f3-83d2-4ace-a288-daef7c31abe4o%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAJP%3DbzAF4%2Bsty9iRRBo3DabH9ZMGKf38-hnGzMZ4cJjry6OZtA%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/CAMyDDM1j4yvaxBLwrXm%3DmJ1AvnXWMYjdfq%2BJZ-L8ocRE7iKhng%40mail.gmail.com.

Re: Rethink (?) how we handle security headers.

[Sci Mithilesh]

Your contact number send me I want a VIP site

On Thu, 30 Jul 2020, 2:37 pm Carlton Gibson, 
wrote:

> Hi.
>
> (This is quite preliminary but...)
>
> So we added support for Referrer-Policy in 3.0
> https://docs.djangoproject.com/en/3.0/ref/middleware/#referrer-policy
>
> This added the SECURE_REFERRER_POLICY setting.
>
> We have a Someday/Maybe Permissions-Policy (was Feature-Policy).
> for https://code.djangoproject.com/ticket/30746
>
> Then a proposal for a new one Cross-Origin Opener Policy
> https://code.djangoproject.com/ticket/31840
>
> > This can be implemented in a similar way to the Referrer-Policy header
> in the security middleware.
>
> But are we going to continue to add settings along this line, one for
> every new header that comes up?
>
> Maybe, but I feel like we might need to review how we handle such things.
>
>
> One thought that has come up (here and elsewhere) is that it would be good
> if Middleware could be configured with parameters without having to
> subclass. I wonder if (I suspect) that has come up as an idea before?
>
>
> Otherwise does anyone have thoughts on this issue? (Maybe we can just keep
> adding settings — we have a lot for *_COOKIE_* for example.)
>
>
> Thanks,
> Carlton
>
> --
> 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/f35d51f3-83d2-4ace-a288-daef7c31abe4o%40googlegroups.com
> 
> .
>

-- 
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/CAJP%3DbzAF4%2Bsty9iRRBo3DabH9ZMGKf38-hnGzMZ4cJjry6OZtA%40mail.gmail.com.

Rethink (?) how we handle security headers.

[Carlton Gibson]

Hi.

(This is quite preliminary but...)

So we added support for Referrer-Policy in 3.0
https://docs.djangoproject.com/en/3.0/ref/middleware/#referrer-policy

This added the SECURE_REFERRER_POLICY setting. 

We have a Someday/Maybe Permissions-Policy (was Feature-Policy).
for https://code.djangoproject.com/ticket/30746

Then a proposal for a new one Cross-Origin Opener Policy
https://code.djangoproject.com/ticket/31840

> This can be implemented in a similar way to the Referrer-Policy header in 
the security middleware. 

But are we going to continue to add settings along this line, one for every 
new header that comes up? 

Maybe, but I feel like we might need to review how we handle such things. 


One thought that has come up (here and elsewhere) is that it would be good 
if Middleware could be configured with parameters without having to 
subclass. I wonder if (I suspect) that has come up as an idea before? 


Otherwise does anyone have thoughts on this issue? (Maybe we can just keep 
adding settings — we have a lot for *_COOKIE_* for example.) 


Thanks, 
Carlton

-- 
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/f35d51f3-83d2-4ace-a288-daef7c31abe4o%40googlegroups.com.