Cookies

In this chapter

We'll meet cookies from scratch — how they're set, every real attribute (Domain, Path, Expires, Secure, HttpOnly, SameSite), the real 4KB size limit, and why a cookie's biggest strength (automatic delivery on every request) is also its biggest real cost.

9–11 min

The Problem in Real Life

Act 1 closed with a real diagnosis: GreenMart's lost shopping cart was volatile storage that never got asked to survive a refresh. Sarah opens a fresh tab. "Time to actually fix it," she says. "And the oldest real fix for 'remember something about this visitor' is still worth understanding first — cookies."

Mike has heard the word a thousand times, in every privacy notice GreenMart has ever had to display. He's never actually known what one is.

We ask every visitor to accept cookies. I genuinely don't know what I'm asking them to accept.

Mike

A Note the Server Asks the Browser to Keep, and Return

Real attributes, real security consequences

HttpOnly, Secure, and SameSite each close a specific, real gap — omitting any of them is a real, not theoretical, risk.

Every cookie rides on every request

Unlike other browser storage, cookies are sent automatically on every request to their domain — a real, recurring bandwidth cost.

A cookie is a small piece of data — a name and a value, plus some real rules about it — that a server asks a browser to store, and that the browser then automatically sends back to that same server on every later request. That round-trip, automatic and built into the browser itself, is the one thing that makes cookies genuinely different from every other browser storage mechanism this Act covers.

Setting a cookie, the real mechanism. A server sets a cookie by sending a Set-Cookie header in its response — Set-Cookie: sessionToken=abc123. From then on, the browser attaches Cookie: sessionToken=abc123 to every request it sends back to that server, automatically, without any JavaScript needing to do anything. A page can also set a cookie itself, from JavaScript, via document.cookie — the same underlying store, a different way to write to it.
Real attributes that control real behavior. Domain and Path control which requests a cookie gets attached to. Expires/Max-Age controls how long it survives — omit both, and a cookie is a session cookie, gone when the browser closes; set one, and it's a persistent cookie, surviving a real restart. Secure means the cookie is only ever sent over HTTPS. HttpOnly means JavaScript on the page can't read the cookie at all — a real, specific defense against a malicious script stealing it. SameSite controls whether the cookie gets sent on requests originating from a different site, a real defense against a class of attack called CSRF.
A real, honest size limit. Browsers commit to supporting at least 4KB per cookie, and a real practical limit on how many cookies one domain can set. This matters because — unlike localStorage or IndexedDB, covered next — every single cookie gets sent on every single request to that domain, whether the request actually needs it or not. A bloated cookie is a real, recurring bandwidth cost, paid on every request, forever, not a one-time storage cost.

Table — Cookie Attributes, What Each One Actually Does

Attribute	What It Controls	Real Consequence If Missing
Expires / Max-Age	How long the cookie survives	Without it: a session cookie, gone the moment the browser closes
Secure	Only sent over HTTPS	Without it: the cookie could be sent over plain HTTP, real interception risk
HttpOnly	Blocks JavaScript from reading the cookie	Without it: a malicious script (XSS) could read and steal the cookie's value
SameSite	Whether it's sent on cross-site requests	Without it (or set too loosely): a real CSRF attack surface opens up

None of these are optional extras — each one closes a real, specific gap that an attacker or an accident could otherwise exploit.

This is real, useful territory for GreenMart — a login session token is exactly the kind of thing a cookie, with HttpOnly and Secure set correctly, is genuinely good at. But GreenMart's lost shopping cart is a worse fit than it first looks: a cart can grow to hold many items, and every byte of it would ride along on every single request to GreenMart's site, whether that request needed the cart or not. That's a real, honest reason to keep looking at the next chapter's own mechanism instead.

Key Takeaway

A cookie's real superpower — getting sent automatically, on every request, without any code asking for it — is also its real cost. That trade-off is worth naming honestly before reaching for a cookie by habit.

Why This Matters

GreenMart already uses cookies, in the consent banner every visitor sees, without most of the team ever knowing what specific attributes are actually protecting (or not protecting) real customer data. Understanding the real mechanism is what turns that consent banner from legal boilerplate into an actual, informed decision.

GreenMart now has the real mechanism behind cookies — genuinely good for a login session token, genuinely a poor fit for a growing shopping cart. The next chapter meets the browser's own purpose-built alternative for exactly this kind of larger, JavaScript-only data: localStorage.