Basic

Sessions & Cookies

How a website remembers you're logged in after one password, and the ways that memory gets abused.

What's a session?

The web has no memory: to a server, every request looks like it's from a brand-new stranger. So when you log in, the server hands your browser a cookie: a small token, like a coat-check ticket. Your browser automatically sends that ticket back on every later request, and the server uses it to recognize you. That running "you're still logged in" state is a session.

The cookie doesn't contain your identity. It's a claim ticket; the real record lives on the server, and the server decides whether to honor it.

What can go wrong

The ticket expiresSessions time out after a while. The browser may still hold the cookie, but the server stops honoring it, so you're logged out.

Someone uses your ticket against youAnother website can quietly make your browser fire a request at a site you're logged into, and your cookie rides along automatically. That's cross-site request forgery (CSRF).

A ticket planted before loginIf the session isn't refreshed at login, an attacker who set it earlier can ride your logged-in session. Fixed by issuing a fresh session when you sign in.

Two defenses show up below: a secret token tied to your session that other sites can't guess, and a check on which site the request came from. Reading is safe; the checks bite when a request tries to change something.

See it break — then see it caught

Each button fires a real request at the same rules a hardened server runs. Predict first: allowed or blocked? Then click. The decision on the right names the check that caught it.

Predict the outcome, then pick an example to see the decision and why.