Session Management

HTTP, the protocol that powers the entire web, has a fundamental design constraint that shapes everything we build: it's stateless. Every single request is independent. The server has no built-in memory of who you are or what you did 2 seconds ago.

Think about that. You log into Amazon. You add a laptop to your cart. You navigate to checkout. From HTTP's perspective, those are three completely unrelated requests from a stranger on the internet. The server has zero inherent reason to connect them.

So how does Amazon know you're logged in? How does it remember your cart? How does it know that the person clicking "Place Order" is the same person who logged in 10 minutes ago?

Session management. It's the set of techniques that give the illusion of continuity on top of a fundamentally amnesiac protocol. Every time you stay logged in, every shopping cart that persists across pages, every "remember me" checkbox, that's session management at work.

And getting it wrong has real consequences. In 2012, GitHub had a mass account hijack because of a session management vulnerability. Attackers could forge session cookies and take over any account. Session management isn't just a feature, it's a security boundary.

The oldest and most proven approach to session management uses server-side sessions with cookies. Here's how it works.

The Flow

1. You submit your username and password
2. The server verifies them against the database
3. If correct, the server creates a session, an object in server memory (or a database) that stores your user ID, role, and session metadata
4. The server generates a random session ID (like abc123def456) and stores it as the key for that session object
5. The server sends back a response with a Set-Cookie header: session_id=abc123def456
6. Your browser stores this cookie and automatically sends it with every subsequent request to that domain
7. On each request, the server reads the session ID from the cookie, looks up the session in its storage, and knows who you are

Why Session IDs, Not User Data?

The cookie only contains a random ID, not your username, role, or any real data. This is intentional.

If the cookie contained user=admin&role=superuser, anyone could edit their cookie to user=admin&role=superuser and become admin. By storing only a random, unguessable session ID, the actual data stays on the server where users can't tamper with it.

Cookie Security Settings

Cookies have several flags that control their security:

A properly configured session cookie looks like:

Set-Cookie: session_id=abc123def456; HttpOnly; Secure; SameSite=Strict; Max-Age=86400; Path=/