HTTP Cookies

A cookie is a small piece of state that a server asks a browser to store and send back on later requests. Cookies exist because HTTP is stateless by default. Without some shared state, a site cannot easily remember that you logged in, kept items in a basket, changed language, or dismissed a banner.

A typical cookie starts with a Set-Cookie header in an HTTP response. The browser stores that value along with rules that define when it should be sent again. On later requests to matching URLs, the browser adds a Cookie header automatically. The server then interprets that value as a session identifier, a preference flag, or some other application state. In most production systems, the cookie itself is not the session. It is a lookup key that lets the server fetch the real session data from a database or cache.

Several attributes matter more than the name and value. Expires or Max-Age decides whether the cookie survives past the current browser session. Domain and Path scope where the browser will send it. Secure means it should travel only over HTTPS. HttpOnly prevents JavaScript from reading it, which reduces the damage from some cross site scripting bugs. SameSite controls whether the browser should attach the cookie on cross site requests, which is now an important defence against cross site request forgery.

That mechanism is simple, but the operational tradeoffs are real. Cookies are attached to many requests, so oversized cookies add bandwidth and latency to every page load. Browsers also cap cookie size and count, so treating them as general storage does not scale. Storing sensitive data directly in a cookie is risky unless it is carefully signed and, where necessary, encrypted. Even then, revocation becomes awkward because old copies may still be valid until expiry.

Cookies are also a privacy boundary. First party cookies are set by the site the user is visiting and are still central to login and preference flows. Third party cookies are set in cross site contexts and were heavily used for tracking and advertising. Modern browsers increasingly restrict or block those patterns, which is why many authentication and analytics designs have had to change.

The practical lesson is that cookies are best used for small, explicit state with clear security settings. A session cookie with Secure, HttpOnly, and an appropriate SameSite policy is a common pattern. A signed preference cookie can also work well for non sensitive state. What cookies are not good at is acting as a general database, a safe home for secrets, or a substitute for careful session design. They are a transport mechanism for browser state, and their value comes from using that mechanism narrowly and deliberately.