On Sun, Sep 26, 2021 at 10:24 AM Neil Madden <[email protected]> wrote:
> Right, cookie prefixes is one approach - but still has a little way to go > on browser share [1]. > Fwiw, a big part of that "missing" browser share is Safari on iOS (14.25% of global share), and I just tested on devices through BrowserStack on https://googlechrome.github.io/samples/cookie-prefixes/ and it *does* support cookie prefixes (tested with v14 and v13). > > In my book (have I mentioned my book? :-)), I show a variant of the > double-submit cookie pattern in which the anti-CSRF token is a SHA-256 hash > of the session cookie [2], which prevents the cookie being overridden. > > We should probably just defer to the security considerations in > rfc6265-bis [3], which already discusses some limitations of SameSite and > recommends it be used as a defence-in-depth alongside traditional defences. > +1, just mentioning that there should be CSRF mitigations in place should be enough IMO. Also maybe mention that securing the API is then actually outside the scope of the BCP (whose role in this case is only to recommend *not* using OAuth) -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
