Giving a Stateless Protocol a Memory

HTTP is stateless by design, yet every login-protected website remembers who you are across dozens of requests. That continuity comes from cookies and the session abstraction layered on top of them.

How Cookies Work

A server sets a cookie in a response header:

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

The client stores it and then attaches it automatically to every subsequent request for the matching scope:

Cookie: session_id=abc123

A cookie has several attributes:

  • Domain: which hosts receive it. Omitting it restricts the cookie to the exact origin.
  • Path: restricts it to a URL prefix.
  • Expires / Max-Age: a persistent cookie expires; a session cookie is deleted when the browser closes.
  • HttpOnly: the cookie is invisible to JavaScript—critical defense against XSS-based session theft.
  • Secure: only sent over HTTPS.
  • SameSite: Strict, Lax, or None, controlling when the cookie is sent on cross-site requests. Lax is the modern default and blocks most CSRF.

Server-Side Sessions

The most common pattern stores only an opaque session ID in the cookie; all real state lives on the server, keyed by that ID. The server validates the ID on every request and looks up the associated user, cart, or privileges. Because the client never sees the data, server-side sessions are safe from cookie tampering—but they require shared storage (Redis, a database) so every server in a load-balanced fleet can read the same session.

Stateless Sessions and JWTs

The other major pattern stores the session state in the cookie itself as a signed token. A JSON Web Token (JWT) is a base64-encoded JSON payload plus a cryptographic signature. The server verifies the signature and trusts the payload without a database lookup.

JWTs scale beautifully and are easy to use across services, but they introduce hard tradeoffs: - They cannot be easily revoked before their expiry, because there is no server-side record. - They are larger than a session ID, adding bytes to every request. - The payload is base64, not encrypted—anyone can read it; only the signature prevents tampering.

Session Security Essentials

  • Session fixation: always regenerate the session ID on login; never accept a client-supplied ID.
  • Expiry: set realistic idle and absolute timeouts. A session should not live forever because a tab stayed open.
  • Rotation: refresh tokens should rotate on every use so a stolen refresh token is detected when the legitimate client uses the old one.
  • Scope creep: cookies set for example.com are sent to every subdomain. A cookie for a shared host can leak to unrelated tenants.

Cookies in a Scraping Context

If you automate browser flows (logins, carts), you are essentially juggling cookies. Persist the cookie jar between runs, keep the same IP for the session's lifetime, and re-solve any challenge before the cookie requires renewal. The lesson is identical from both sides of the wire: state lives in cookies, and whoever holds the cookie holds the session.