Enforcing the __Host-Http- prefix not only affects JS readability, but also writeability from JS (e.g., an attacker writing a cookie through an XSS attack vector). That’s why the spec explicitly states
This helps developers and server operators to know that the cookie was set using a Set-Cookie header These prefixes are minor tweaks to the security model of the web, but they do offer benefits and exist for a reason. These should become the default for all cookies used, but each time I cover this topic in training, almost no-one knows about cookie prefixes. It would be a bit of a missed opportunity to release a browser-oriented spec without recommending the best practices currently available, hence my request to update. Looking forward to finalizing the Browser-based apps BCP Philippe — Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com > On 27 Jun 2026, at 04:03, Dhruv Agnihotri <[email protected]> wrote: > > +1 to publishing. The "for example" softening is the right call. > > On Neil's question, I read the new prefix as adding a property, though a > narrow one, and the "why did HTTPbis add these" question is answered by > design rather than by attack. > > The layered-cookies draft is structured as orthogonal, composable prefix > primitives: `__Host-` enforces origin scoping (Secure + Path=/ + no Domain), > `__Http-` enforces non-JS-readability (Secure + HttpOnly), and `__Host-Http-` > composes both. Over the existing `__Host-` plus the BCP's `MUST HttpOnly`, > the property `__Host-Http-` adds is that HttpOnly enforcement moves from > server-side policy to user-agent rejection — layered-cookies §4.1.3.4 plus > the cookie filtering algorithm has the UA drop a `__Host-Http-`-named cookie > that arrives without HttpOnly. > > For a spec-compliant deployment this changes nothing; for an operator > regression (misconfigured framework, alternate session code path, a > downgraded middleware that silently drops the flag) it's a UA-side catch in > browsers that have shipped the prefix. So no new attack class against the > BCP-conformant baseline, but a defense-in-depth layer for the case the MUST > is unintentionally violated. > > On that basis the example framing reads right: worth pointing at as the > direction of travel, not worth making the BCP's binding analysis depend on. > > (I covered the BFF section of -26 in an InfoQ piece earlier this year, "The > DPoP Storage Paradox > <https://www.infoq.com/articles/dpop-key-storage-unsolved-problem/>", happy > to dig into specifics on or off list if useful.) > > Dhruv Agnihotri > [email protected] <mailto:[email protected]> > > > On Fri, Jun 26, 2026 at 3:19 AM Neil Madden <[email protected] > <mailto:[email protected]>> wrote: >> >> >> > On 26 Jun 2026, at 00:50, Aaron Parecki >> > <[email protected] <mailto:[email protected]>> >> > wrote: >> > >> > Hi all, >> > >> > As you probably know, the "OAuth for Browser-Based Apps BCP" document has >> > been stuck in the editor's queue for almost a year waiting on the >> > publication of RFC6265bis. In the meantime, the HTTPbis working group has >> > revised the recommendation in RFC6265bis that we reference, changing the >> > recommendation from prefixing cookies with "__Host-" to "__Host-Http-" in >> > a new document draft-ietf-httpbis-layered-cookies. >> >> >From what I can see, they've not changed it, they've introduced another set >> >of prefixes. The __Host- prefix still exists, it just doesn't require the >> >HttpOnly flag on cookies that are set. Given that the BCP already says >> >HttpOnly is a MUST, I'm not sure what this adds? >> >> Does anyone know why the HTTPBis WG added these new prefixes? The old ones >> address known concrete security gaps, but I don't see an attack that this >> new prefix prevents. >> >> -- Neil >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
