Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Philippe De Ryck]

Answers inline to add the proper nuance. 

> Would you not agree that a "good" CSP config is a good line of defense 
> against XSS attacks?

A good CSP policy can indeed help to stop the exploitation of an XSS 
vulnerability, should one exist in the application. I do not agree with the 
wording “a good line of defense”, as it can imply that a good CSP policy can be 
used as the only defense. XSS vulnerabilities are first and foremost avoided by 
adopting secure coding guidelines. CSP acts as a second line of defense, in 
case an XSS vulnerability still slips through. 


> I agree that the OAuth BCP should not provide details on CSP config. I do 
> think we should call out having a considered CSP config is a best practice.
> 
> I differentiate between headers and cookies and SQL injection etc. in that 
> the headers and cookies are part of the HTTP requests, which is the protocol 
> OAuth is built on, so weaknesses there weaken the protocol. 

Just because CSP can be configured as a header (CSP can also be set with a 
 tag) does not make it part of the protocol OAuth is built on. CSP is 
100% an application-level feature. And as useful as CSP can be, I would not 
consider “not having CSP” as a protocol weakness.

I’m not strongly against mentioning CSP, I’m just wondering how much good it 
does given the complexity of configuring CSP correctly. It suffices to include 
a CDN that hosts a version of AngularJS 1.x to have a bypassable (and thereby 
mostly useless) CSP policy. 
 
Philippe


> 
> On Mon, Nov 6, 2023 at 11:25 AM Philippe De Ryck 
>  > wrote:
> I went back to the Security BCP and combed through the fine details, and 
> there is indeed some guidance on CSP. But your initial remark that this is 
> "vague" is definitely true, and this section is actually a good illustration 
> of what I was trying to say. Let me unpack the details a bit …
> 
> In section 4.16, the security BCP talks about how to restrict framing to 
> avoid clickjacking/UI redressing attacks. Defending against such attacks 
> cannot be done with secure coding, but must be done with specific framing 
> restrictions. The best mechanism to achieve this is by setting security 
> headers: the legacy X-Frame-Options header or the more modern CSP 
> frame-ancestors directive. Given that this security requirement is closely 
> linked to OAuth and is not something that “happens naturally”, but must be 
> explicitly added, I totally agree that this should be part of the security 
> BCP. 
> 
> Now, in paragraph 5 of the section, things get somewhat confusing (included 
> below for reference). So far, every mention of "CSP" was used as a synonym 
> for the "frame-ancestors" directive to restrict framing. However, all the way 
> at the end of that paragraph, the text suddenly recommends using the 
> "script-src" directive to restrict sources of JS that can execute on the 
> page. The paragraph then points to a sample header, with the configuration of 
> "script-src 'self'". 
> 
> Using CSP allows authorization servers to specify multiple origins in a 
> single response header field and to constrain these using flexible patterns 
> (see [W3C.CSP-2 ] for details). Level 2 of this 
> standard provides a robust mechanism for protecting against clickjacking by 
> using policies that restrict the origin of frames (using frame-ancestors) 
> together with those that restrict the sources of scripts allowed to execute 
> on an HTML page (by using script-src).
> 
> Unfortunately, this advice is too simplistic to be useful, as it prevents the 
> loading of JS from any other origin, including CDNs, or third-party services. 
> Additionally, it violates modern best practices for CSP, which recommend the 
> use of hashes, nonces, and trust propagation (with nonce propagation or 
> 'strict-dynamic'). If you’re interested in the details, I’ve done a few guest 
> blog posts about CSP for Auth0 that cover this: 
> https://auth0.com/blog/authors/philippe-de-rick/ 
> 
> 
> 
> What I'm trying to say here is that a detailed CSP config (apart from the 
> "frame-ancestors" directive) is not essential for a secure OAuth 
> implementation or deployment. It can and should act as a second line of 
> defense against content injection attacks, but not having such a CSP config 
> does not automatically create a vulnerability. Therefore, my recommendation 
> is to focus on the details directly relevant to OAuth security.
> 
> For security guidelines for configuring cookies, I believe this would be more 
> directly related and more useful, as I mentioned before.
> 
> Finally, I can totally see that the community could benefit from more 
> in-depth security best practices that go beyond OAuth-specific risks. Apart 
> from CSP, there's a whole bunch more response headers that can be configured 
> (as you and others have mentioned). On top of that, modern browsers 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

Would you not agree that a "good" CSP config is a good line of defense
against XSS attacks?

I agree that the OAuth BCP should not provide details on CSP config. I do
think we should call out having a considered CSP config is a best practice.

I differentiate between headers and cookies and SQL injection etc. in that
the headers and cookies are part of the HTTP requests, which is the
protocol OAuth is built on, so weaknesses there weaken the protocol.

On Mon, Nov 6, 2023 at 11:25 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> I went back to the Security BCP and combed through the fine details, and
> there is indeed some guidance on CSP. But your initial remark that this is
> "vague" is definitely true, and this section is actually a good
> illustration of what I was trying to say. Let me unpack the details a bit …
>
> In section 4.16, the security BCP talks about how to restrict framing to
> avoid clickjacking/UI redressing attacks. Defending against such attacks
> cannot be done with secure coding, but must be done with specific framing
> restrictions. The best mechanism to achieve this is by setting security
> headers: the legacy X-Frame-Options header or the more modern CSP
> frame-ancestors directive. Given that this security requirement is closely
> linked to OAuth and is not something that “happens naturally”, but must be
> explicitly added, I totally agree that this should be part of the security
> BCP.
>
> Now, in paragraph 5 of the section, things get somewhat confusing
> (included below for reference). So far, every mention of "CSP" was used as
> a synonym for the "frame-ancestors" directive to restrict framing. However,
> all the way at the end of that paragraph, the text suddenly recommends
> using the "script-src" directive to restrict sources of JS that can execute
> on the page. The paragraph then points to a sample header, with the
> configuration of "script-src 'self'".
>
> *Using CSP allows authorization servers to specify multiple origins in a
> single response header field and to constrain these using flexible patterns
> (see [W3C.CSP-2 ] for details). Level 2 of this
> standard provides a robust mechanism for protecting against clickjacking by
> using policies that restrict the origin of frames (using frame-ancestors)
> together with those that restrict the sources of scripts allowed to execute
> on an HTML page (by using script-src).*
>
> Unfortunately, this advice is too simplistic to be useful, as it prevents
> the loading of JS from any other origin, including CDNs, or third-party
> services. Additionally, it violates modern best practices for CSP, which
> recommend the use of hashes, nonces, and trust propagation (with nonce
> propagation or 'strict-dynamic'). If you’re interested in the details, I’ve
> done a few guest blog posts about CSP for Auth0 that cover this:
> https://auth0.com/blog/authors/philippe-de-rick/
>
>
> What I'm trying to say here is that a detailed CSP config (apart from the
> "frame-ancestors" directive) is not essential for a secure OAuth
> implementation or deployment. It can and should act as a second line of
> defense against content injection attacks, but not having such a CSP config
> does not automatically create a vulnerability. Therefore, my recommendation
> is to focus on the details directly relevant to OAuth security.
>
> For security guidelines for configuring cookies, I believe this would be
> more directly related and more useful, as I mentioned before.
>
> Finally, I can totally see that the community could benefit from more
> in-depth security best practices that go beyond OAuth-specific risks. Apart
> from CSP, there's a whole bunch more response headers that can be
> configured (as you and others have mentioned). On top of that, modern
> browsers send a lot of metadata in a request (e.g., the Sec-Fetch Metadata
> headers) that could be used by the AS to reject illegitimate requests.
> However, given the rapid development of these features and lack of
> widespread support, I would envision such recommendations to live in a more
> "dynamic" document than an RFC.
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com
>
> On 6 Nov 2023, at 18:07, Dick Hardt  wrote:
>
> That's a surprising response Philippe. The BCP already has
> Content-Security-Policy and Referrer-Policy headers recommendations. The
> core of my feedback is to add Cookie and Header best practices to Section
> 2, and point to one or more living documents.
>
> On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> wrote:
>
>> While I understand the idea of pointing to additional security resources,
>> I’m not sure if it is the role of the security BCP (or other specs) to take
>> on the responsibility to address these issues. In my point of view, the
>> security BCP should focus on OAuth aspects, and discuss security topics
>> that are directly 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Philippe De Ryck]

I went back to the Security BCP and combed through the fine details, and there 
is indeed some guidance on CSP. But your initial remark that this is "vague" is 
definitely true, and this section is actually a good illustration of what I was 
trying to say. Let me unpack the details a bit …

In section 4.16, the security BCP talks about how to restrict framing to avoid 
clickjacking/UI redressing attacks. Defending against such attacks cannot be 
done with secure coding, but must be done with specific framing restrictions. 
The best mechanism to achieve this is by setting security headers: the legacy 
X-Frame-Options header or the more modern CSP frame-ancestors directive. Given 
that this security requirement is closely linked to OAuth and is not something 
that “happens naturally”, but must be explicitly added, I totally agree that 
this should be part of the security BCP. 

Now, in paragraph 5 of the section, things get somewhat confusing (included 
below for reference). So far, every mention of "CSP" was used as a synonym for 
the "frame-ancestors" directive to restrict framing. However, all the way at 
the end of that paragraph, the text suddenly recommends using the "script-src" 
directive to restrict sources of JS that can execute on the page. The paragraph 
then points to a sample header, with the configuration of "script-src 'self'". 

Using CSP allows authorization servers to specify multiple origins in a single 
response header field and to constrain these using flexible patterns (see 
[W3C.CSP-2 ] for details). Level 2 of this standard 
provides a robust mechanism for protecting against clickjacking by using 
policies that restrict the origin of frames (using frame-ancestors) together 
with those that restrict the sources of scripts allowed to execute on an HTML 
page (by using script-src).

Unfortunately, this advice is too simplistic to be useful, as it prevents the 
loading of JS from any other origin, including CDNs, or third-party services. 
Additionally, it violates modern best practices for CSP, which recommend the 
use of hashes, nonces, and trust propagation (with nonce propagation or 
'strict-dynamic'). If you’re interested in the details, I’ve done a few guest 
blog posts about CSP for Auth0 that cover this: 
https://auth0.com/blog/authors/philippe-de-rick/


What I'm trying to say here is that a detailed CSP config (apart from the 
"frame-ancestors" directive) is not essential for a secure OAuth implementation 
or deployment. It can and should act as a second line of defense against 
content injection attacks, but not having such a CSP config does not 
automatically create a vulnerability. Therefore, my recommendation is to focus 
on the details directly relevant to OAuth security.

For security guidelines for configuring cookies, I believe this would be more 
directly related and more useful, as I mentioned before.

Finally, I can totally see that the community could benefit from more in-depth 
security best practices that go beyond OAuth-specific risks. Apart from CSP, 
there's a whole bunch more response headers that can be configured (as you and 
others have mentioned). On top of that, modern browsers send a lot of metadata 
in a request (e.g., the Sec-Fetch Metadata headers) that could be used by the 
AS to reject illegitimate requests. However, given the rapid development of 
these features and lack of widespread support, I would envision such 
recommendations to live in a more "dynamic" document than an RFC.

Philippe

—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com

> On 6 Nov 2023, at 18:07, Dick Hardt  wrote:
> 
> That's a surprising response Philippe. The BCP already has 
> Content-Security-Policy and Referrer-Policy headers recommendations. The core 
> of my feedback is to add Cookie and Header best practices to Section 2, and 
> point to one or more living documents. 
> 
> On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryck 
>  > wrote:
>> While I understand the idea of pointing to additional security resources, 
>> I’m not sure if it is the role of the security BCP (or other specs) to take 
>> on the responsibility to address these issues. In my point of view, the 
>> security BCP should focus on OAuth aspects, and discuss security topics that 
>> are directly relevant to that purpose. 
>> 
>> Concretely for the security mechanisms discussed here, I can see how cookie 
>> configurations could be relevant (the session with the AS is inherent to 
>> OAuth), but I don’t see defenses such as CSP as relevant in that scope. If 
>> these are in scope, should we then also provide advice or pointers on 
>> avoiding server-side implementation vulnerabilities, such as SQL injection 
>> or SSRF?
>> 
>> Additionally, many of these security mechanisms are quite complex and 
>> non-trivial to deploy. For example, adding a generic pointer stating “you 
>> should add CSP” does not say 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

That's a surprising response Philippe. The BCP already has
Content-Security-Policy and Referrer-Policy headers recommendations. The
core of my feedback is to add Cookie and Header best practices to Section
2, and point to one or more living documents.

On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> While I understand the idea of pointing to additional security resources,
> I’m not sure if it is the role of the security BCP (or other specs) to take
> on the responsibility to address these issues. In my point of view, the
> security BCP should focus on OAuth aspects, and discuss security topics
> that are directly relevant to that purpose.
>
> Concretely for the security mechanisms discussed here, I can see how
> cookie configurations could be relevant (the session with the AS is
> inherent to OAuth), but I don’t see defenses such as CSP as relevant in
> that scope. If these are in scope, should we then also provide advice or
> pointers on avoiding server-side implementation vulnerabilities, such as
> SQL injection or SSRF?
>
> Additionally, many of these security mechanisms are quite complex and
> non-trivial to deploy. For example, adding a generic pointer stating “you
> should add CSP” does not say much, as CSP can control more than a dozen
> features.
>
> To summarize, I would keep the scope of these specs as narrow as possible
> and avoid aiming to address security concerns that are beyond the realm of
> OAuth.
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com
>
> On 6 Nov 2023, at 15:39, Dick Hardt  wrote:
>
> +1 to referring to calling out that cookies / headers should follow best
> security practice, and pointing to living documents
>
> On Mon, Nov 6, 2023 at 6:21 AM Giuseppe De Marco 
> wrote:
>
>> Hi,
>>
>> everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
>> different projects and orgs, I have included secured web cookie in
>> the recipe.
>> For the implementation profile of OpenID4VP I did the same, where the
>> secured and httponly cookie is used an in particular as a basic security
>> requirement for the cross device flow [1].
>>
>> Even if I got perfectly Daniel's and Aaron's editorial strategy and I
>> agree, I think that Dick's proposal and your confirmation on that, Neil, is
>> something to take into account to bring developers awareness during the
>> implementation phases.
>> A ref to living OWASP specs surrounded by a generic refs to the user
>> agent security, even if out of scope, I think that should be in the specs.
>>
>> [1]
>> https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow
>>
>> Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden <
>> neil.e.mad...@gmail.com> ha scritto:
>>
>>> Although I think we could add some basic advice, the list of security
>>> headers to use is still evolving. For example, there were several headers
>>> added after Spectre to limit cross-site interactions. And then there’s
>>> things like the “X-XSS-Protection” header, which was best practice to add
>>> to responses not too long ago but has now been universally removed from
>>> browsers as it enabled certain content disclosure attacks.
>>>
>>> Cookie security attributes are perhaps a bit more stable, but in general
>>> we probably just want to point people at “living” guidance like OWASP.
>>>
>>> — Neil
>>>
>>> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
>>>
>>> The cookie and header recommendations I am thinking of would be for the
>>> AS as well as the client.
>>>
>>> A number of XSS attacks can be thwarted by a modern browser and the
>>> right HTTP headers.
>>>
>>> My question is: Did the authors consider adding cookie and header
>>> recommendations, and decided it was too general?
>>>
>>> Cookie and header best security practices have been around for years --
>>> I'm not suggesting we make anything up -- I'm suggesting we raise
>>> awareness.
>>>
>>> I consider myself to be fairly security aware, and I was not aware of
>>> some of the HTTP headers that are best security practice.
>>>
>>> /Dick
>>>
>>>
>>> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki >> 40parecki@dmarc.ietf.org> wrote:
>>>
 I don't think it's necessary to say "do the right things with cookies"
 in the Security BCP. The Browser Apps BCP has a much deeper discussion of
 how different browser-based architectures work with cookies so that seems
 like a better place to actually have a real discussion about it.

 Also +1 to what Daniel said about not continuing to add little things.
 Plus I think it's too late anyway, publication has already been requested
 for the Security BCP.

 Aaron

 On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett >>> 40danielfett...@dmarc.ietf.org> wrote:

> I agree with Aaron!
>
> Also we should be very careful about any additions to the Security BCP
> at this 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Philippe De Ryck]

While I understand the idea of pointing to additional security resources, I’m 
not sure if it is the role of the security BCP (or other specs) to take on the 
responsibility to address these issues. In my point of view, the security BCP 
should focus on OAuth aspects, and discuss security topics that are directly 
relevant to that purpose. 

Concretely for the security mechanisms discussed here, I can see how cookie 
configurations could be relevant (the session with the AS is inherent to 
OAuth), but I don’t see defenses such as CSP as relevant in that scope. If 
these are in scope, should we then also provide advice or pointers on avoiding 
server-side implementation vulnerabilities, such as SQL injection or SSRF?

Additionally, many of these security mechanisms are quite complex and 
non-trivial to deploy. For example, adding a generic pointer stating “you 
should add CSP” does not say much, as CSP can control more than a dozen 
features. 

To summarize, I would keep the scope of these specs as narrow as possible and 
avoid aiming to address security concerns that are beyond the realm of OAuth.

Philippe

—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com

> On 6 Nov 2023, at 15:39, Dick Hardt  wrote:
> 
> +1 to referring to calling out that cookies / headers should follow best 
> security practice, and pointing to living documents
> 
> On Mon, Nov 6, 2023 at 6:21 AM Giuseppe De Marco  > wrote:
>> Hi,
>> 
>> everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for different 
>> projects and orgs, I have included secured web cookie in the recipe.
>> For the implementation profile of OpenID4VP I did the same, where the 
>> secured and httponly cookie is used an in particular as a basic security 
>> requirement for the cross device flow [1].
>> 
>> Even if I got perfectly Daniel's and Aaron's editorial strategy and I agree, 
>> I think that Dick's proposal and your confirmation on that, Neil, is 
>> something to take into account to bring developers awareness during the 
>> implementation phases.
>> A ref to living OWASP specs surrounded by a generic refs to the user agent 
>> security, even if out of scope, I think that should be in the specs.
>> 
>> [1] 
>> https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow
>> 
>> Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden > > ha scritto:
>>> Although I think we could add some basic advice, the list of security 
>>> headers to use is still evolving. For example, there were several headers 
>>> added after Spectre to limit cross-site interactions. And then there’s 
>>> things like the “X-XSS-Protection” header, which was best practice to add 
>>> to responses not too long ago but has now been universally removed from 
>>> browsers as it enabled certain content disclosure attacks.
>>> 
>>> Cookie security attributes are perhaps a bit more stable, but in general we 
>>> probably just want to point people at “living” guidance like OWASP.
>>> 
>>> — Neil
>>> 
 On 5 Nov 2023, at 19:28, Dick Hardt >>> > wrote:
 
 The cookie and header recommendations I am thinking of would be for the AS 
 as well as the client. 
 
 A number of XSS attacks can be thwarted by a modern browser and the right 
 HTTP headers.
 
 My question is: Did the authors consider adding cookie and header 
 recommendations, and decided it was too general? 
 
 Cookie and header best security practices have been around for years -- 
 I'm not suggesting we make anything up -- I'm suggesting we raise 
 awareness. 
 
 I consider myself to be fairly security aware, and I was not aware of some 
 of the HTTP headers that are best security practice. 
 
 /Dick
 
 
 On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki 
 mailto:40parecki@dmarc.ietf.org>> 
 wrote:
> I don't think it's necessary to say "do the right things with cookies" in 
> the Security BCP. The Browser Apps BCP has a much deeper discussion of 
> how different browser-based architectures work with cookies so that seems 
> like a better place to actually have a real discussion about it.
> 
> Also +1 to what Daniel said about not continuing to add little things. 
> Plus I think it's too late anyway, publication has already been requested 
> for the Security BCP.
> 
> Aaron
> 
> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett 
>  > wrote:
>> I agree with Aaron! 
>> 
>> Also we should be very careful about any additions to the Security BCP 
>> at this point. It is very easy to re-start the "one more thing" loop 
>> we've been stuck in for the last years. There may be more useful things 
>> to say, but we should put them on the list for a future second 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

+1 to referring to calling out that cookies / headers should follow best
security practice, and pointing to living documents

On Mon, Nov 6, 2023 at 6:21 AM Giuseppe De Marco 
wrote:

> Hi,
>
> everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
> different projects and orgs, I have included secured web cookie in
> the recipe.
> For the implementation profile of OpenID4VP I did the same, where the
> secured and httponly cookie is used an in particular as a basic security
> requirement for the cross device flow [1].
>
> Even if I got perfectly Daniel's and Aaron's editorial strategy and I
> agree, I think that Dick's proposal and your confirmation on that, Neil, is
> something to take into account to bring developers awareness during the
> implementation phases.
> A ref to living OWASP specs surrounded by a generic refs to the user agent
> security, even if out of scope, I think that should be in the specs.
>
> [1]
> https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow
>
> Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden <
> neil.e.mad...@gmail.com> ha scritto:
>
>> Although I think we could add some basic advice, the list of security
>> headers to use is still evolving. For example, there were several headers
>> added after Spectre to limit cross-site interactions. And then there’s
>> things like the “X-XSS-Protection” header, which was best practice to add
>> to responses not too long ago but has now been universally removed from
>> browsers as it enabled certain content disclosure attacks.
>>
>> Cookie security attributes are perhaps a bit more stable, but in general
>> we probably just want to point people at “living” guidance like OWASP.
>>
>> — Neil
>>
>> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
>>
>> The cookie and header recommendations I am thinking of would be for the
>> AS as well as the client.
>>
>> A number of XSS attacks can be thwarted by a modern browser and the right
>> HTTP headers.
>>
>> My question is: Did the authors consider adding cookie and header
>> recommendations, and decided it was too general?
>>
>> Cookie and header best security practices have been around for years --
>> I'm not suggesting we make anything up -- I'm suggesting we raise
>> awareness.
>>
>> I consider myself to be fairly security aware, and I was not aware of
>> some of the HTTP headers that are best security practice.
>>
>> /Dick
>>
>>
>> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote:
>>
>>> I don't think it's necessary to say "do the right things with cookies"
>>> in the Security BCP. The Browser Apps BCP has a much deeper discussion of
>>> how different browser-based architectures work with cookies so that seems
>>> like a better place to actually have a real discussion about it.
>>>
>>> Also +1 to what Daniel said about not continuing to add little things.
>>> Plus I think it's too late anyway, publication has already been requested
>>> for the Security BCP.
>>>
>>> Aaron
>>>
>>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett >> 40danielfett...@dmarc.ietf.org> wrote:
>>>
 I agree with Aaron!

 Also we should be very careful about any additions to the Security BCP
 at this point. It is very easy to re-start the "one more thing" loop we've
 been stuck in for the last years. There may be more useful things to say,
 but we should put them on the list for a future second version of the BCP.

 -Daniel
 Am 05.11.23 um 20:03 schrieb Aaron Parecki:

 I don't think the Security BCP should incorporate cookie best practices
 directly in the document. If anything, it sounds like possibly a candidate
 for inclusion in the Browser Apps BCP.

 There are already some mentions of these cookie properties mentioned in
 the Browser Apps BCP, though only in reference to specific architectures,
 not as a general best practice. For example:


 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

 Aaron

 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt 
 wrote:

> Hey
>
> I was reviewing security on some sites I managed and checked to see if
> the recommendations were in the BCP.
>
> I don't see anything around cookies such as httpOnly, sameSite,
> secure.
>
> I saw some HTTP security header suggestions buried in 4.16
> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
> rather vague.
>
> I understand these are general web security best practices, and
> perhaps I missed it, but I think it would be useful to call out that best
> security practices around cookies and headers should also be followed in
> Section 2, and either have the best practices included, or direct the
> reader where to find them.
>
> 

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Giuseppe De Marco]

Hi,

everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for
different projects and orgs, I have included secured web cookie in
the recipe.
For the implementation profile of OpenID4VP I did the same, where the
secured and httponly cookie is used an in particular as a basic security
requirement for the cross device flow [1].

Even if I got perfectly Daniel's and Aaron's editorial strategy and I
agree, I think that Dick's proposal and your confirmation on that, Neil, is
something to take into account to bring developers awareness during the
implementation phases.
A ref to living OWASP specs surrounded by a generic refs to the user agent
security, even if out of scope, I think that should be in the specs.

[1]
https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow

Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden 
ha scritto:

> Although I think we could add some basic advice, the list of security
> headers to use is still evolving. For example, there were several headers
> added after Spectre to limit cross-site interactions. And then there’s
> things like the “X-XSS-Protection” header, which was best practice to add
> to responses not too long ago but has now been universally removed from
> browsers as it enabled certain content disclosure attacks.
>
> Cookie security attributes are perhaps a bit more stable, but in general
> we probably just want to point people at “living” guidance like OWASP.
>
> — Neil
>
> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
>
> The cookie and header recommendations I am thinking of would be for the AS
> as well as the client.
>
> A number of XSS attacks can be thwarted by a modern browser and the right
> HTTP headers.
>
> My question is: Did the authors consider adding cookie and header
> recommendations, and decided it was too general?
>
> Cookie and header best security practices have been around for years --
> I'm not suggesting we make anything up -- I'm suggesting we raise
> awareness.
>
> I consider myself to be fairly security aware, and I was not aware of some
> of the HTTP headers that are best security practice.
>
> /Dick
>
>
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> I don't think it's necessary to say "do the right things with cookies" in
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how
>> different browser-based architectures work with cookies so that seems like
>> a better place to actually have a real discussion about it.
>>
>> Also +1 to what Daniel said about not continuing to add little things.
>> Plus I think it's too late anyway, publication has already been requested
>> for the Security BCP.
>>
>> Aaron
>>
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett > 40danielfett...@dmarc.ietf.org> wrote:
>>
>>> I agree with Aaron!
>>>
>>> Also we should be very careful about any additions to the Security BCP
>>> at this point. It is very easy to re-start the "one more thing" loop we've
>>> been stuck in for the last years. There may be more useful things to say,
>>> but we should put them on the list for a future second version of the BCP.
>>>
>>> -Daniel
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>>>
>>> I don't think the Security BCP should incorporate cookie best practices
>>> directly in the document. If anything, it sounds like possibly a candidate
>>> for inclusion in the Browser Apps BCP.
>>>
>>> There are already some mentions of these cookie properties mentioned in
>>> the Browser Apps BCP, though only in reference to specific architectures,
>>> not as a general best practice. For example:
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>>>
>>> Aaron
>>>
>>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>>>
 Hey

 I was reviewing security on some sites I managed and checked to see if
 the recommendations were in the BCP.

 I don't see anything around cookies such as httpOnly, sameSite, secure.

 I saw some HTTP security header suggestions buried in 4.16
 (X-Frame-Options, CSP), but not for Strict-Transport-Security,
 Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
 rather vague.

 I understand these are general web security best practices, and perhaps
 I missed it, but I think it would be useful to call out that best security
 practices around cookies and headers should also be followed in Section 2,
 and either have the best practices included, or direct the reader where to
 find them.

 /Dick

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Neil Madden]

Although I think we could add some basic advice, the list of security headers 
to use is still evolving. For example, there were several headers added after 
Spectre to limit cross-site interactions. And then there’s things like the 
“X-XSS-Protection” header, which was best practice to add to responses not too 
long ago but has now been universally removed from browsers as it enabled 
certain content disclosure attacks.

Cookie security attributes are perhaps a bit more stable, but in general we 
probably just want to point people at “living” guidance like OWASP.

— Neil

> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
> 
> The cookie and header recommendations I am thinking of would be for the AS as 
> well as the client. 
> 
> A number of XSS attacks can be thwarted by a modern browser and the right 
> HTTP headers.
> 
> My question is: Did the authors consider adding cookie and header 
> recommendations, and decided it was too general? 
> 
> Cookie and header best security practices have been around for years -- I'm 
> not suggesting we make anything up -- I'm suggesting we raise awareness. 
> 
> I consider myself to be fairly security aware, and I was not aware of some of 
> the HTTP headers that are best security practice. 
> 
> /Dick
> 
> 
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki 
> mailto:40parecki@dmarc.ietf.org>> 
> wrote:
>> I don't think it's necessary to say "do the right things with cookies" in 
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how 
>> different browser-based architectures work with cookies so that seems like a 
>> better place to actually have a real discussion about it.
>> 
>> Also +1 to what Daniel said about not continuing to add little things. Plus 
>> I think it's too late anyway, publication has already been requested for the 
>> Security BCP.
>> 
>> Aaron
>> 
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett 
>> > > wrote:
>>> I agree with Aaron! 
>>> 
>>> Also we should be very careful about any additions to the Security BCP at 
>>> this point. It is very easy to re-start the "one more thing" loop we've 
>>> been stuck in for the last years. There may be more useful things to say, 
>>> but we should put them on the list for a future second version of the BCP.
>>> 
>>> -Daniel
>>> 
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
 I don't think the Security BCP should incorporate cookie best practices 
 directly in the document. If anything, it sounds like possibly a candidate 
 for inclusion in the Browser Apps BCP. 
 
 There are already some mentions of these cookie properties mentioned in 
 the Browser Apps BCP, though only in reference to specific architectures, 
 not as a general best practice. For example:
 
 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
 
 Aaron
 
 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt >>> > wrote:
> Hey
> 
> I was reviewing security on some sites I managed and checked to see if 
> the recommendations were in the BCP.
> 
> I don't see anything around cookies such as httpOnly, sameSite, secure. 
> 
> I saw some HTTP security header suggestions buried in 4.16 
> (X-Frame-Options, CSP), but not for Strict-Transport-Security, 
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is 
> rather vague.
> 
> I understand these are general web security best practices, and perhaps I 
> missed it, but I think it would be useful to call out that best security 
> practices around cookies and headers should also be followed in Section 
> 2, and either have the best practices included, or direct the reader 
> where to find them.
> 
> /Dick
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org 
 https://www.ietf.org/mailman/listinfo/oauth
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Neil Madden]

Although I think we could add some basic advice, the list of security headers 
to use is still evolving. For example, there were several headers added after 
Spectre to limit cross-site interactions. And then there’s things like the 
“X-XSS-Protection” header, which was best practice to add to responses not too 
long ago but has now been universally removed from browsers as it enabled 
certain content disclosure attacks.

Cookie security attributes are perhaps a bit more stable, but in general we 
probably just want to point people at “living” guidance like OWASP.

— Neil

> On 5 Nov 2023, at 19:28, Dick Hardt  wrote:
> 
> The cookie and header recommendations I am thinking of would be for the AS as 
> well as the client. 
> 
> A number of XSS attacks can be thwarted by a modern browser and the right 
> HTTP headers.
> 
> My question is: Did the authors consider adding cookie and header 
> recommendations, and decided it was too general? 
> 
> Cookie and header best security practices have been around for years -- I'm 
> not suggesting we make anything up -- I'm suggesting we raise awareness. 
> 
> I consider myself to be fairly security aware, and I was not aware of some of 
> the HTTP headers that are best security practice. 
> 
> /Dick
> 
> 
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki 
> mailto:40parecki@dmarc.ietf.org>> 
> wrote:
>> I don't think it's necessary to say "do the right things with cookies" in 
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how 
>> different browser-based architectures work with cookies so that seems like a 
>> better place to actually have a real discussion about it.
>> 
>> Also +1 to what Daniel said about not continuing to add little things. Plus 
>> I think it's too late anyway, publication has already been requested for the 
>> Security BCP.
>> 
>> Aaron
>> 
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett 
>> > > wrote:
>>> I agree with Aaron! 
>>> 
>>> Also we should be very careful about any additions to the Security BCP at 
>>> this point. It is very easy to re-start the "one more thing" loop we've 
>>> been stuck in for the last years. There may be more useful things to say, 
>>> but we should put them on the list for a future second version of the BCP.
>>> 
>>> -Daniel
>>> 
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
 I don't think the Security BCP should incorporate cookie best practices 
 directly in the document. If anything, it sounds like possibly a candidate 
 for inclusion in the Browser Apps BCP. 
 
 There are already some mentions of these cookie properties mentioned in 
 the Browser Apps BCP, though only in reference to specific architectures, 
 not as a general best practice. For example:
 
 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
 
 Aaron
 
 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt >>> > wrote:
> Hey
> 
> I was reviewing security on some sites I managed and checked to see if 
> the recommendations were in the BCP.
> 
> I don't see anything around cookies such as httpOnly, sameSite, secure. 
> 
> I saw some HTTP security header suggestions buried in 4.16 
> (X-Frame-Options, CSP), but not for Strict-Transport-Security, 
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is 
> rather vague.
> 
> I understand these are general web security best practices, and perhaps I 
> missed it, but I think it would be useful to call out that best security 
> practices around cookies and headers should also be followed in Section 
> 2, and either have the best practices included, or direct the reader 
> where to find them.
> 
> /Dick
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
 
 
 ___
 OAuth mailing list
 OAuth@ietf.org 
 https://www.ietf.org/mailman/listinfo/oauth
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

And Google is not following setting the Referrer-Policy header

https://securityheaders.com/?q=https%3A%2F%2Faccounts.google.com=on

On Sun, Nov 5, 2023 at 11:35 AM Dick Hardt  wrote:

> For example, Auth0 has not set any CSP on this endpoint:
>
> https://securityheaders.com/?q=https%3A%2F%2Fauth0.openai.com
>
> The CSP recommendations are buried in the BCP currently
>
> On Sun, Nov 5, 2023 at 11:28 AM Dick Hardt  wrote:
>
>> The cookie and header recommendations I am thinking of would be for the
>> AS as well as the client.
>>
>> A number of XSS attacks can be thwarted by a modern browser and the right
>> HTTP headers.
>>
>> My question is: Did the authors consider adding cookie and header
>> recommendations, and decided it was too general?
>>
>> Cookie and header best security practices have been around for years --
>> I'm not suggesting we make anything up -- I'm suggesting we raise
>> awareness.
>>
>> I consider myself to be fairly security aware, and I was not aware of
>> some of the HTTP headers that are best security practice.
>>
>> /Dick
>>
>>
>> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote:
>>
>>> I don't think it's necessary to say "do the right things with cookies"
>>> in the Security BCP. The Browser Apps BCP has a much deeper discussion of
>>> how different browser-based architectures work with cookies so that seems
>>> like a better place to actually have a real discussion about it.
>>>
>>> Also +1 to what Daniel said about not continuing to add little things.
>>> Plus I think it's too late anyway, publication has already been requested
>>> for the Security BCP.
>>>
>>> Aaron
>>>
>>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett >> 40danielfett...@dmarc.ietf.org> wrote:
>>>
 I agree with Aaron!

 Also we should be very careful about any additions to the Security BCP
 at this point. It is very easy to re-start the "one more thing" loop we've
 been stuck in for the last years. There may be more useful things to say,
 but we should put them on the list for a future second version of the BCP.

 -Daniel
 Am 05.11.23 um 20:03 schrieb Aaron Parecki:

 I don't think the Security BCP should incorporate cookie best practices
 directly in the document. If anything, it sounds like possibly a candidate
 for inclusion in the Browser Apps BCP.

 There are already some mentions of these cookie properties mentioned in
 the Browser Apps BCP, though only in reference to specific architectures,
 not as a general best practice. For example:


 https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

 Aaron

 On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt 
 wrote:

> Hey
>
> I was reviewing security on some sites I managed and checked to see if
> the recommendations were in the BCP.
>
> I don't see anything around cookies such as httpOnly, sameSite,
> secure.
>
> I saw some HTTP security header suggestions buried in 4.16
> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
> rather vague.
>
> I understand these are general web security best practices, and
> perhaps I missed it, but I think it would be useful to call out that best
> security practices around cookies and headers should also be followed in
> Section 2, and either have the best practices included, or direct the
> reader where to find them.
>
> /Dick
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

 ___
 OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

For example, Auth0 has not set any CSP on this endpoint:

https://securityheaders.com/?q=https%3A%2F%2Fauth0.openai.com

The CSP recommendations are buried in the BCP currently

On Sun, Nov 5, 2023 at 11:28 AM Dick Hardt  wrote:

> The cookie and header recommendations I am thinking of would be for the AS
> as well as the client.
>
> A number of XSS attacks can be thwarted by a modern browser and the right
> HTTP headers.
>
> My question is: Did the authors consider adding cookie and header
> recommendations, and decided it was too general?
>
> Cookie and header best security practices have been around for years --
> I'm not suggesting we make anything up -- I'm suggesting we raise
> awareness.
>
> I consider myself to be fairly security aware, and I was not aware of some
> of the HTTP headers that are best security practice.
>
> /Dick
>
>
> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> I don't think it's necessary to say "do the right things with cookies" in
>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how
>> different browser-based architectures work with cookies so that seems like
>> a better place to actually have a real discussion about it.
>>
>> Also +1 to what Daniel said about not continuing to add little things.
>> Plus I think it's too late anyway, publication has already been requested
>> for the Security BCP.
>>
>> Aaron
>>
>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett > 40danielfett...@dmarc.ietf.org> wrote:
>>
>>> I agree with Aaron!
>>>
>>> Also we should be very careful about any additions to the Security BCP
>>> at this point. It is very easy to re-start the "one more thing" loop we've
>>> been stuck in for the last years. There may be more useful things to say,
>>> but we should put them on the list for a future second version of the BCP.
>>>
>>> -Daniel
>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>>>
>>> I don't think the Security BCP should incorporate cookie best practices
>>> directly in the document. If anything, it sounds like possibly a candidate
>>> for inclusion in the Browser Apps BCP.
>>>
>>> There are already some mentions of these cookie properties mentioned in
>>> the Browser Apps BCP, though only in reference to specific architectures,
>>> not as a general best practice. For example:
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>>>
>>> Aaron
>>>
>>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>>>
 Hey

 I was reviewing security on some sites I managed and checked to see if
 the recommendations were in the BCP.

 I don't see anything around cookies such as httpOnly, sameSite, secure.

 I saw some HTTP security header suggestions buried in 4.16
 (X-Frame-Options, CSP), but not for Strict-Transport-Security,
 Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
 rather vague.

 I understand these are general web security best practices, and perhaps
 I missed it, but I think it would be useful to call out that best security
 practices around cookies and headers should also be followed in Section 2,
 and either have the best practices included, or direct the reader where to
 find them.

 /Dick

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>>
>>> ___
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

The cookie and header recommendations I am thinking of would be for the AS
as well as the client.

A number of XSS attacks can be thwarted by a modern browser and the right
HTTP headers.

My question is: Did the authors consider adding cookie and header
recommendations, and decided it was too general?

Cookie and header best security practices have been around for years -- I'm
not suggesting we make anything up -- I'm suggesting we raise awareness.

I consider myself to be fairly security aware, and I was not aware of some
of the HTTP headers that are best security practice.

/Dick


On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki  wrote:

> I don't think it's necessary to say "do the right things with cookies" in
> the Security BCP. The Browser Apps BCP has a much deeper discussion of how
> different browser-based architectures work with cookies so that seems like
> a better place to actually have a real discussion about it.
>
> Also +1 to what Daniel said about not continuing to add little things.
> Plus I think it's too late anyway, publication has already been requested
> for the Security BCP.
>
> Aaron
>
> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> I agree with Aaron!
>>
>> Also we should be very careful about any additions to the Security BCP at
>> this point. It is very easy to re-start the "one more thing" loop we've
>> been stuck in for the last years. There may be more useful things to say,
>> but we should put them on the list for a future second version of the BCP.
>>
>> -Daniel
>> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>>
>> I don't think the Security BCP should incorporate cookie best practices
>> directly in the document. If anything, it sounds like possibly a candidate
>> for inclusion in the Browser Apps BCP.
>>
>> There are already some mentions of these cookie properties mentioned in
>> the Browser Apps BCP, though only in reference to specific architectures,
>> not as a general best practice. For example:
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>>
>> Aaron
>>
>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>>
>>> Hey
>>>
>>> I was reviewing security on some sites I managed and checked to see if
>>> the recommendations were in the BCP.
>>>
>>> I don't see anything around cookies such as httpOnly, sameSite, secure.
>>>
>>> I saw some HTTP security header suggestions buried in 4.16
>>> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
>>> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
>>> rather vague.
>>>
>>> I understand these are general web security best practices, and perhaps
>>> I missed it, but I think it would be useful to call out that best security
>>> practices around cookies and headers should also be followed in Section 2,
>>> and either have the best practices included, or direct the reader where to
>>> find them.
>>>
>>> /Dick
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Aaron Parecki]

I don't think it's necessary to say "do the right things with cookies" in
the Security BCP. The Browser Apps BCP has a much deeper discussion of how
different browser-based architectures work with cookies so that seems like
a better place to actually have a real discussion about it.

Also +1 to what Daniel said about not continuing to add little things. Plus
I think it's too late anyway, publication has already been requested for
the Security BCP.

Aaron

On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett  wrote:

> I agree with Aaron!
>
> Also we should be very careful about any additions to the Security BCP at
> this point. It is very easy to re-start the "one more thing" loop we've
> been stuck in for the last years. There may be more useful things to say,
> but we should put them on the list for a future second version of the BCP.
>
> -Daniel
> Am 05.11.23 um 20:03 schrieb Aaron Parecki:
>
> I don't think the Security BCP should incorporate cookie best practices
> directly in the document. If anything, it sounds like possibly a candidate
> for inclusion in the Browser Apps BCP.
>
> There are already some mentions of these cookie properties mentioned in
> the Browser Apps BCP, though only in reference to specific architectures,
> not as a general best practice. For example:
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>
> Aaron
>
> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>
>> Hey
>>
>> I was reviewing security on some sites I managed and checked to see if
>> the recommendations were in the BCP.
>>
>> I don't see anything around cookies such as httpOnly, sameSite, secure.
>>
>> I saw some HTTP security header suggestions buried in 4.16
>> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
>> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
>> rather vague.
>>
>> I understand these are general web security best practices, and perhaps I
>> missed it, but I think it would be useful to call out that best security
>> practices around cookies and headers should also be followed in Section 2,
>> and either have the best practices included, or direct the reader where to
>> find them.
>>
>> /Dick
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Daniel Fett]

I agree with Aaron!

Also we should be very careful about any additions to the Security BCP 
at this point. It is very easy to re-start the "one more thing" loop 
we've been stuck in for the last years. There may be more useful things 
to say, but we should put them on the list for a future second version 
of the BCP.


-Daniel

Am 05.11.23 um 20:03 schrieb Aaron Parecki:
I don't think the Security BCP should incorporate cookie best 
practices directly in the document. If anything, it sounds like 
possibly a candidate for inclusion in the Browser Apps BCP.


There are already some mentions of these cookie properties mentioned 
in the Browser Apps BCP, though only in reference to specific 
architectures, not as a general best practice. For example:


https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

Aaron

On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:

Hey

I was reviewing security on some sites I managed and checked to
see if the recommendations were in the BCP.

I don't see anything around cookies such as httpOnly, sameSite,
secure.

I saw some HTTP security header suggestions buried in 4.16
(X-Frame-Options, CSP), but not for Strict-Transport-Security,
Permissions-Policy, or X-Content-Type-Options, and the CSP
guidance is rather vague.

I understand these are general web security best practices, and
perhaps I missed it, but I think it would be useful to call out
that best security practices around cookies and headers should
also be followed in Section 2, and either have the best practices
included, or direct the reader where to find them.

/Dick

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

The only rationale for incorporating cookie and header best practices in
the BCP would be if there is not a "good" reference to refer the reader to.

Aaron: Do you agree that the BCP should call out that cookie and
header best practices should be followed?

On Sun, Nov 5, 2023 at 11:03 AM Aaron Parecki  wrote:

> I don't think the Security BCP should incorporate cookie best practices
> directly in the document. If anything, it sounds like possibly a candidate
> for inclusion in the Browser Apps BCP.
>
> There are already some mentions of these cookie properties mentioned in
> the Browser Apps BCP, though only in reference to specific architectures,
> not as a general best practice. For example:
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>
> Aaron
>
> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:
>
>> Hey
>>
>> I was reviewing security on some sites I managed and checked to see if
>> the recommendations were in the BCP.
>>
>> I don't see anything around cookies such as httpOnly, sameSite, secure.
>>
>> I saw some HTTP security header suggestions buried in 4.16
>> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
>> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
>> rather vague.
>>
>> I understand these are general web security best practices, and perhaps I
>> missed it, but I think it would be useful to call out that best security
>> practices around cookies and headers should also be followed in Section 2,
>> and either have the best practices included, or direct the reader where to
>> find them.
>>
>> /Dick
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Aaron Parecki]

I don't think the Security BCP should incorporate cookie best practices
directly in the document. If anything, it sounds like possibly a candidate
for inclusion in the Browser Apps BCP.

There are already some mentions of these cookie properties mentioned in the
Browser Apps BCP, though only in reference to specific architectures, not
as a general best practice. For example:

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security

Aaron

On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt  wrote:

> Hey
>
> I was reviewing security on some sites I managed and checked to see if the
> recommendations were in the BCP.
>
> I don't see anything around cookies such as httpOnly, sameSite, secure.
>
> I saw some HTTP security header suggestions buried in 4.16
> (X-Frame-Options, CSP), but not for Strict-Transport-Security,
> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
> rather vague.
>
> I understand these are general web security best practices, and perhaps I
> missed it, but I think it would be useful to call out that best security
> practices around cookies and headers should also be followed in Section 2,
> and either have the best practices included, or direct the reader where to
> find them.
>
> /Dick
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

[Dick Hardt]

Hey

I was reviewing security on some sites I managed and checked to see if the
recommendations were in the BCP.

I don't see anything around cookies such as httpOnly, sameSite, secure.

I saw some HTTP security header suggestions buried in 4.16
(X-Frame-Options, CSP), but not for Strict-Transport-Security,
Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is
rather vague.

I understand these are general web security best practices, and perhaps I
missed it, but I think it would be useful to call out that best security
practices around cookies and headers should also be followed in Section 2,
and either have the best practices included, or direct the reader where to
find them.

/Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth