Cookie prefixes - No more insecure cookies!

Just like SameSite-cookies I've also been keeping an eye on Cookie prefixes for some while now. I tested to see if it was supported in latest Chrome-dev and it was! So this will be a short blog post that explains what Cookie Prefixes are and how they may protect the user.


Change the cookie, not its attributes!

Cookie prefixes are a new mechanism from HTTPbis that extends the cookies feature by simply requiring cookies with a specific prefix to only be used if certain criteria are met.

Because we are changing the actual cookie name rather than adding attributes a party can't alter the cookie preferences because the server would reject the cookies if the name for the cookie was wrong.

The two prefixes are __Secure- and __Host-. These need to be used as prefixes in the cookie name and not as the value! So for example, if your site already has a cookie with the name sid the cookie would have the new name of __Secure-sid to take advantage of cookie prefixes.

The `__Secure-' prefix

If a cookie has a name with the prefix __Secure- the cookie must have the Secure-attribute and be set from a secure origin; that is [secure] HTTPS.

The `__Host-' prefix

If a cookie has a name with the prefix __Host- the cookie must also have the Secure-attribute, but NOT the Domain-attribute because the origin from where the cookie was sent can only be used as the domain for the cookie. Also, the path must be /.

That's it! Easy to implement and use. But why does cookie prefixes make cookies more secure?


Cookie prefixes make things a little more secure

Cookie prefixes addresses some issues with today's cookies and the main goal is to eliminate a secure origin to set a cookie that can be used over a non-secure origin and vice versa.

It can also protect against cookie injection because with the prefix __Host- only the origin can set cookies.

If you're using HTTPS for your website and relies on cookies for authentication, consider adding the __Host- attribute to your cookies to make things little more secure than before.


EDIT:

Got a question on Twitter. I'm sorry if I'm being unclear, but the main goal with Cookie prefixes is that instead of using cookie attributes, the name of the cookie is changed.

feel free to test my PoC: http://sweha.xxx/k.php

c@c# curl -sI http://sweha.xxx/k.php | grep ^Set

Set-cookie: __Secure-lol=foo;Domain=sweha.xxx

And you will see that it will not set the cookie in Chrome-dev. That's because the origin is not secure.

While in Firefox: