Re: _HttpOnly cookie prefix?

Yoav,

First, I personally don't like the use of the double-underscore prefixes -
it seems like there has been low takeup so far (but that's just anecdata) -
it feels like (is?) a hack that was added after the cookie mechanism was
created.

To be clear, this requirement applies to the server, but you're
implementing it by adding code in the client (browser) to disallow the
cookie from being created in the first place?

Wouldn't the server *know* whether or not it had created a given cookie
during a previous interaction with the client? I would think the server
should be keeping track of this...?

 Or is your concern about a malicious client updating an existing cookie
that was originally created via a "Set-Cookie" header sent form the server?

Rory

On Wed, Feb 19, 2025 at 6:21 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Feb 19, 2025 at 2:11 PM Yoav Weiss <yoav.weiss@shopify.com> wrote:
> > Looking at the current prefixes, it might be fitting to add an
> "__HttpOnly" prefix that would have the following semantics:
> > * The cookie is rejected if it's set as a client-side cookie, rather
> than through a `Set-Cookie` header
> > * The cookie is rejected if it's set without an "HttpOnly" attribute
> >
> > Does this make rough sense?
>
> At the very least it should minimally enforce __Secure- semantics, but
> this raises the question of what should happen if you also want to
> enforce __Host-. And also what adoption of these prefixes has been
> thus far. Because if it's very low it's a bit unclear if we should
> continue to invest in them as they do require checks all over the
> place.
>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt