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 <dick.ha...@gmail.com> 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=40parecki....@dmarc.ietf.org <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 >> <fett=40danielfett...@dmarc.ietf.org >> <mailto: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 <dick.ha...@gmail.com >>>> <mailto:dick.ha...@gmail.com>> 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 <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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
