Cookies and how sites remember you

Log into a site, click around for twenty minutes, and it still knows who you are on every single page. That shouldn't be possible from anything you've read in this series so far. Every HTTP request in lesson 5 stands completely alone: the server that handles your tenth request has no memory of your ninth. Something has to carry your identity forward, request after request, and that something is a cookie.

HTTP forgets everything by design

This amnesia isn't a bug. It's what makes HTTP simple and scalable: a server can handle a request from anyone without keeping track of who asked what before, and any server behind a load balancer can answer any request without needing to have seen your history. But a shopping cart, a logged-in session, "remember me," all of that requires some persistent memory across requests. HTTP itself won't give it to you. Cookies are the patch.

How a cookie actually gets set

The server sends a Set-Cookie header in its response, telling the browser to hold onto a small piece of text and send it back on every future request to that domain.

HTTP/1.1 200 OK
Set-Cookie: session_id=a8f3e91c; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
Content-Type: text/html

The browser stores session_id=a8f3e91c and, from that point on, attaches it automatically to every request it sends back to that same domain, without your JavaScript needing to do anything.

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session_id=a8f3e91c

That session_id is usually an opaque, random string, not something meaningful on its own. The server keeps the actual session data (which user this is, when it expires) in its own storage, keyed by that string. The cookie's whole job is to be the key the browser hands back on every request, so the server can find the right session without you logging in again on every page.

What actually lives in the cookie

A common early mistake is stuffing real user data straight into the cookie, user=Diya;role=admin, and trusting it. Don't. Cookies are stored on the user's machine and can be edited by anyone with browser dev tools open. A cookie that says role=admin in plain text is an invitation to change it to exactly that.

The standard pattern is the opaque session token you saw above: the cookie holds a random ID with no meaning by itself, and the actual data lives server-side, looked up by that ID. Nothing valuable is ever sitting in the browser for someone to tamper with. An alternative, common in APIs, is a signed token like a JWT, where the data does travel inside the cookie but is cryptographically signed, so tampering with it invalidates the signature and the server rejects it. Either way, the rule is the same: never trust cookie contents unless they're either opaque or verifiably signed.

The flags that make a cookie safe

Three attributes on Set-Cookie do most of the real security work:

• HttpOnly blocks JavaScript from reading the cookie at all. If a site has an XSS vulnerability (malicious script running on the page), HttpOnly stops that script from stealing the session cookie directly. It can still do damage while it runs, but it can't walk off with your login.
• Secure means the browser will only ever send this cookie over HTTPS, never plain HTTP. Without it, a session token could be sniffed by anyone on the same network as an unencrypted request goes by.
• SameSite controls whether the cookie gets sent on requests originating from a different site. SameSite=Lax, the modern default in most browsers, blocks the cookie on cross-site requests except top-level navigation, which cuts off a lot of cross-site request forgery attacks by default. SameSite=Strict is even tighter. SameSite=None sends it everywhere, which some legitimate cross-site integrations need, but it requires Secure alongside it.

Sessions vs. long-lived cookies

Not every cookie is about login state. A Max-Age or Expires attribute controls how long the browser holds onto it: omit both and it's a session cookie, gone when the browser closes. Set Max-Age=2592000 (30 days) and it survives across browser restarts, which is what "remember me" checkboxes are actually setting under the hood.

Cookies also set up the next lesson directly. A browser attaching your session cookie automatically to every request to a domain matters a lot, and it's exactly why browsers had to build a separate wall around which other sites are allowed to trigger requests that use it. On to CORS: why the browser blocked your request.