HTTP Cookies

HTTP is stateless in the sense that one request does not automatically remember the previous one. Cookies are one of the main ways the web adds continuity on top of that model. A server sends a Set-Cookie header in a response, the browser stores the value according to its rules, and future requests that match the cookie's scope include it in the Cookie header.

What a cookie actually contains

A cookie is just a small key-value pair plus metadata. The metadata decides when the browser sends it back. Domain and path limit where it applies. Expiry or max-age decides whether it is a session cookie or a persistent one. Secure says it should only travel over HTTPS. HttpOnly keeps JavaScript from reading it directly. SameSite controls when the browser includes it on cross-site requests, which matters for CSRF defence.

That metadata is often more important than the value itself. Two cookies with the same name can behave differently if their scope differs. Bugs around scope are common when applications move between subdomains or introduce separate API hosts.

Why servers use cookies

The most common use is session management. Instead of storing a password or user record in the browser, the server stores a session identifier in a cookie and keeps the real state server-side. Cookies are also used for language preferences, consent state, shopping basket continuity, and experiment bucketing.

A cookie is not a magic secure container. If you put sensitive data directly into it, that data is exposed to whoever can read the browser storage or intercept the request on an insecure connection. Signed or encrypted cookies can help with tampering or confidentiality, but they still need correct scoping and expiry.

Practical limits and modern constraints

Cookies are small and travel on every matching request, so they should stay compact. Oversized cookies waste bandwidth and can break in surprising ways when browser or proxy limits are exceeded. They are also not a substitute for general client storage. Large application state belongs elsewhere.

Modern browsers have become stricter about third-party cookies and tracking behaviour. This changes how embedded widgets, federated login flows, and advertising systems work. A design that depends heavily on cross-site cookie access now needs much more careful review.

A good mental model

Think of a cookie as a note the browser agrees to attach when certain rules match. The server writes the note, the browser enforces the scope, and every request pays the cost of carrying it. Use cookies for continuity, keep the contents minimal, and set the flags deliberately so the convenience of state does not become a security problem.

For API-heavy applications, another design choice is whether authentication should use cookies or explicit bearer tokens. Cookies work well with browsers because they integrate with request handling automatically, but they demand careful CSRF and scope configuration. The better option depends on the client and threat model, not on fashion.