Cookies and sessions: how a website remembers you

Yesterday we saw that HTTP has no memory. Every request arrives at the server as if from a stranger. Yet you log in to your email once and it stays open for weeks. Something has to bridge that gap.

That something is the cookie, and the idea it supports is the session. Together they’re behind almost every login on the web, which also makes them one of the things attackers want most.

The cloakroom ticket

Think of a cloakroom at an event. You hand over your coat and get a small numbered ticket. The ticket isn’t your coat, and it says nothing about you. But whoever shows that ticket gets the coat back, no questions asked.

A login session works the same way:

1. You send your username and password once.
2. The server checks them, creates a session on its side (“ticket 48213 belongs to Priya, logged in at 9:02”), and hands your browser a random session ID.
3. Your browser stores that ID in a cookie and sends it with every later request to the same site.
4. The server looks up the ID, sees it belongs to Priya, and treats the request as hers.

Your password crosses the wire once. After that, the session ID is the key.

What a cookie actually is

A cookie is just a small named value the server asks the browser to keep. It arrives in a response header:

Set-Cookie: session=f3a9c1e07b4d...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=86400

After that, the browser adds it to every matching request:

Cookie: session=f3a9c1e07b4d...

Cookies are used for other things too: remembering a dark-mode setting, a language, or what’s in a shopping cart. Those are low-stakes. A cookie that keeps you logged in is not.

Why it matters for security

Because the session ID is the key, anyone who gets a copy of it can act as you until it expires. They don’t need your password, and they often skip your two-factor check too, since that already happened at login.

That’s why so much web security is really about protecting this one value. The main threats, at a high level:

• Theft over the network: if the cookie ever travels over plain HTTP, anyone on the same network path can read it.
• Theft by script: if a site has a cross-site scripting bug (Day 19), injected JavaScript may be able to read cookies and send them elsewhere.
• Theft from the device: malware on a computer can copy cookies straight out of the browser. This is a growing problem, and it’s why reputable sites now watch for sessions suddenly being used from a new place.
• Misuse from another site: a malicious page can make your browser send a request to a site you’re logged in to, and the browser may attach your cookie automatically. This is called cross-site request forgery.
• Guessable or reused IDs: if session IDs are predictable, or the same ID is kept before and after login, an attacker may be able to guess or plant one.

The four settings that protect a cookie

The good news is that browsers give site owners strong tools, mostly in that one Set-Cookie line:

Setting	What it tells the browser	What it stops
Secure	Only send this cookie over HTTPS	Reading it off the network
HttpOnly	Don’t let JavaScript read it	Scripts stealing it
SameSite=Lax or Strict	Don’t attach it to requests started by other sites	Most cross-site request forgery
Max-Age or Expires	Throw it away after this long	Old stolen cookies working forever

A session cookie without Secure and HttpOnly in 2026 is a red flag. Day 10 goes deeper into getting every one of these right.

What good sites also do

Cookie settings are half the story. The server side matters too:

• Long, random session IDs generated by a proper library, never something like a user number or a timestamp.
• A fresh session ID at login. The old one is thrown away, so nobody can plant an ID on you in advance and wait.
• Real logout. Pressing “Log out” should delete the session on the server, not just the cookie in your browser.
• Sensible timeouts. Banking sites log you out after minutes of inactivity. A social app might keep you in for weeks. The right choice depends on what’s at stake.
• “Log out all devices”. A button that ends every session lets people recover quickly if a laptop is lost or a cookie is stolen.
• Re-asking for the password before sensitive actions like changing an email address, even inside a valid session.

See your own cookies

You can look at the cookies any site has given you:

1. Press F12 to open developer tools.
2. In Chrome or Edge, open Application, then Cookies. In Firefox, it’s Storage, then Cookies.
3. Click the site’s name and look at the columns for Secure, HttpOnly and SameSite.

Try it on a site you log in to. The cookie with a long random value and all three protections ticked is usually the session.

What you can do today

If you browse the web:

1. Log out of important accounts on shared or public computers. That ends the session instead of leaving the ticket lying around.
2. Use “log out of all devices” in your email and social accounts if you ever lose a device or see a login you don’t recognise.
3. Don’t install browser extensions you don’t need. Some ask for permission to read every site’s data, cookies included.

If you run a website:

1. Check your login cookie has Secure, HttpOnly and SameSite set. The Application tab shows you in seconds.
2. Make sure a new session ID is issued at login and the session is destroyed on the server at logout.
3. Set an idle timeout that fits what your site protects, and offer a way to end all sessions.
4. Use your framework’s built-in session handling instead of writing your own. The OWASP Session Management Cheat Sheet is a good checklist, and MDN’s cookie guide explains every attribute.

Coming up next

On Day 4 we’ll look at HTTPS and the padlock: what that little icon really promises, what it doesn’t, and why “it has a padlock” doesn’t mean a site is safe.