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

[Dick Hardt <[e-mail]>]

And Google is not following setting the Referrer-Policy header

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

On Sun, Nov 5, 2023 at 11:35 AM Dick Hardt <[e-mail]> 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 <[e-mail]> 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 <aaron=
>> [e-mail]> 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 <fett=
>>> [e-mail]> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>