A summary of cookies
A short, technical summary of cookie concepts such as “third party cookies” and cookie attributes such as a expiration date, host-only and SameSite.
Cookies are what we use on the web to persist information between page loads, within and across browsing sessions. If you don’t already know this, I suggest you read one of the many excellent introductions to cookies that are out there. If you do, but want to read a brief but somewhat in-depth summary of important cookie attributes and the sometimes confusing definition of cookies as HTTP only, secure, third party, and so on, read on!
I start this story with a discussion of a cookie’s most important property: its domain. I then give an overview of some restricting properties that impact from where cookies are accessible. Finally, I classify cookies along some other dimensions.
Cookie domain
All cookies are associated with a domain, for example example.com or sub.example.com.
The cookie domain together with its definition as host-only or not (see below) defines which domains “match” the cookie. Which domains “match” in turn determines from where the cookies can be accessible. Cookies are sent along with requests to matching domains, and cookies matching a site’s primary domain are accessible from JavaScript.
Cookies are associated with a domain, and are usually sent along with all requests to domains that it matches.
Host-only cookies match domains that exactly correspond with the domain attribute of the cookie. When setting cookies server-side, host-only is the default in the sense that cookies are host-only unless you specify a cookie’s Domain-attribute; the domain of such cookies is derived from the Host request header.
Non-host-only cookies usually have domains set on them explicitly.¹ Such cookies match the specified domain, or any of its subdomains*.*** For example, a cookie set on mydomain.com would match any request to a page hosted on that domain, such as https://mydomain.com/index.html, or on any of its subdomains, such as requests to https://www.mydomain.com/index.html, https://subdomain.mydomain.com/subersecretdocument.php, https://subsubdomain.subdomain.mydomain.com/cat.gif, ....
¹ Unfortunately, none of the terms “host-additionality”, “host-also” or “host-incorporating” seem to be in active use, so we’re stuck with referring to the latter as “not host-only” or “non-host-only”. If you work for the IETF and looking to draft yet another successor to the RFC 6265 spec… Think about it!
You cannot associate cookies with just any domain. The restriction put on domains is quite elegant: the domain that you set on the cookie, must include the primary domain from which it is set. This essentially means that you can set non-host-only cookies on your own domains or on higher domains (super-domains), and host-only cookies only on your own domain. It is also not possible to set cookies on top-level domain names such as .com or the "catchall" empty domain.
You might have noticed that I said that cookies can be accessible from matching domains. Usually they are, but there are some properties that prevent cookies from being sent or being accessible from matching domains. Let’s look into this closer!
Restricting properties
If domains don’t match, cookies are never accessible or sent along with requests. However, some properties can further restrict whether the cookie is accessible or sent along with requests or not.
Secure ↔️ insecure cookies
Cookies can optionally be marked as secure, which I guess makes all cookies that are not marked as secure insecure. Secure cookies are sent along only with requests that travel over a secure connection; usually this means a HTTPS connection.
The same-site property
Cookies can have a property SameSite that restricts the requests they are sent along with based on the requests' referrer attribute.
If SameSite is set to None, then the cookie is sent along with all requests to matching domains. If SameSite is set to Strict, then the cookie is only send along with requests to matching domains if the request originates from a matching domain as well, so essentially if the request's Referrer header also matches the cookies' domain. The value Lax offers the behavior of Strict but also sends along cookies when users navigates to a matching domain, even if the referring website does not match the cookie's domain.
The default value of SameSite used to be None, but most browsers are now changing this default to Lax (this is a development of early-mid 2020).
HTTP only
This last “restriction” applies to access to cookies from JavaScript, not whether they are sent along with requests or not. Cookies matching the primary domain are usually always accessible from JavaScript. However, if you do not want server-side cookies to be readable from JavaScript, you can restrict this behavior by defining the cookie as a HTTP only cookie by setting its HttpOnly attribute. HTTP only cookies cannot be read client-side.
Other classifiers
There’s several other ways by which we can distinguish cookies that do not relate to their domain or from where they’re accessible.
Client-side ↔️ server-side cookies
Firstly, we can distinguish cookie types depending from where they are set.
Cookies can be set client-side from JavaScript (document.cookie) or server-side through an HTTP response header (set-cookie). Both types of cookies are sent along with HTTP requests (via the Cookie header). Both types of cookies are also accessible from JavaScript, from domains that match the cookie (see below). Access from JavaScript can also be blocked by defining a cookie as a HTTP only cookie (see below).
Although a cookie being client-side or server-side does not directly impact it functionally, browsers can treat them differently (see below).
First-party ↔️ third-party cookies
We can also distinguish cookie types by their origin.
The primary domain is the domain of the site you’re visiting. Any domain that is not the primary domain or a subdomain of the primary domain is a third-party domain.
Cookies set on the primary domain or a parent of the primary domain are called first-party cookies. Cookies that are set or read from an embedded element hosted at a third-party domain are called third-party cookies.
In case you are wondering: “second-party” cookies do not seem like they are really a thing. Also, the same cookie can be first-party or third-party depending on context. For example, when you are visiting Facebook, Facebook’s cookies are first-party cookies. When a Facebook Like-button is embedded on another website, then, within the context of that website, Facebook’s cookies are third-party cookies.
I find the name “third-party cookie” somewhat confusing because it implies that a cookie’s “party” is one of its properties, which is not the case. You can instead think of “first-party” or “third-party” as a (dependent or derived) attribute of the relation between a cookie and the site that it’s being used from.
Again: although a cookie being client-side or server-side does not directly impact it functionally, browsers can treat them differently (see below).
Session ↔️ persistent cookies
We can distinguish cookies by when they expire. By default, cookies are so-called session cookies. They expire as soon as you close the browser; expired cookies are deleted automatically. On the other hand, persistent cookies are cookies with an expiry date or max-age attribute.
Although the expiry date of persistent cookies can be set arbitrarily far into the future, browsers will not always respect this, and can expire cookies sooner. Third-party and client-side cookies are sometimes expired sooner than their first-party and server-side counterparts. For more information, check out my post on tracking prevention in the modern browser:
If your users are using “private” browsing, then cookies are cleared after a browsing session regardless of whether they are configured as persistent. Users can also purge their cookies manually. The point I’m trying to make is: do not rely on persistent cookies actually persisting. Persistent cookies are really not that determined or enduring. They’re irresolute, yielding. Fickle, even. Never store critical information (only) in cookies.
Do not rely on persistent cookies actually persisting
More reading
This article is just a brief overview of important cookie properties. If you’d like to get some more information on the security of cookies or an alternative to cookies called LocalStorage (wel…), I can recommend the following story:
