If you’re in the EU, the chances are you’re all too aware that cookies are everywhere.
Cookie banners remind us every day that our data is being collected and stored, though when asked whether we consent we click accept all without much thought of how cookies work, and what they’re doing in the background while we browse the web.
Mohamad Shiralizadeh, Senior Software Engineer at ING, recently dove deep into the topic of cookies on Coffee with Developers, so watch below or read on to learn more.
How Cookies Work
Originally invented in the 1990s to persist a shopping cart between page refreshes, cookies remain useful for storing data like login status, cart contents, preferences, tracking user activities and more.
At the core, when your browser requests a page, the server responds with a Set-Cookie header telling the browser to store a value, like so:
Set-Cookie: auth=abc123; HttpOnly; Secure; SameSite=Lax
Every subsequent request to that domain includes a Cookie header carrying that value back. The server sets it, browser stores it, browser sends it.
As Mohamed showed in his session, cookies are actually written to a SQLite database on disk, and while they’re encrypted, the key is stored in the macOS keychain and retrievable with a single terminal command, meaning that they’re both more accessible than you might realise, but also less private than you thought.
Cookie Attributes
Cookie attributes can be confusing at first, but getting them right is important. When a server sets a cookie, it can attach attributes that control its scope, lifetime, and security behaviour. Here’s a full example, then we’ll break it down:
Set-Cookie: __Host-session=<signed-token>; Domain=example.com; Path=/; Max-Age=86400; Secure; HttpOnly; SameSite=Lax
Name and Value — To start with, the name is simply the cookie’s identifier (like session or auth), and the value is the data stored against it.
In our example, the name is __Host-session, and while names can be anything, two special prefixes add browser-enforced security rules:
__Secure- ensures the cookie must be sent over HTTPS, and __Host-works the same way but also ensuring it cannot have a Domain attribute. and must use Path=/.
If a cookie uses one of these prefixes but doesn’t meet the conditions, the browser rejects it entirely.
On the value side, you should of course avoid encoding anything meaningful (like a username or role) directly, and while Base64 looks opaque it can easily be manipulated, so you should use signed, opaque session tokens instead.
Domain - By default, a cookie is scoped to the exact host that set it. Setting Domain=example.com extends it to all subdomains, which is convenient, but also a liability on shared domains. This attribute can be used with the __Secure- name, but cannot be included when using __Host-.
Expires / Max-Age - These attributes control deletion time, with Max-Age (seconds) taking priority over Expires. Without either, you get a session cookie deleted when the browser closes, which is a good fallback. While expiry removes the cookie from the browser, a stolen cookie remains valid server-side until explicitly invalidated, so look out for that.
Secure - Restricts the cookie to HTTPS only. Without it, the value travels in plaintext. Always set this for anything sensitive.
HttpOnly - Prevents JavaScript from reading the cookie via document.cookie, blocking XSS-based session theft. You should always set this on session and authentication cookies.
SameSite - Finally, this controls whether a cookie is sent with cross-site requests. If you sent the value to None, no restriction is in place and the cookie is sent with all cross-site requests, and requires Secure, too.
Using Strict ensures they are not sent on cross-site requests, including top-level navigations. For example, users arriving via a link from email will appear logged out on that first request.
Then, there’s Lax. This is the current browser default, and is right for lots of common uses, blocking cross-site sub-requests but allowing top-level navigations.
More on Cookies
Now you know a little more about cookies, go and put what you’ve learned into practice and experiment with them on a project of your own.
Cookies are a lot more interesting - and a lot more powerful - than you might realise, so be sure to watch Mohamed Shiralizadeh’s session Things You Don’t Know About Cookies and How to Protect Them to dive even deeper.