Cookies Done Right

01 What a cookie actually is

A cookie is a tiny key=value string. The server sends Set-Cookie: once; the browser stores it and automatically attaches it to every future request to that site — you don't write any code for the re-sending. That automatic-attachment is the whole point (it's how you stay logged in) and the whole danger (the browser attaches it even when a malicious site triggered the request — that's CSRF, §05).

// Server → browser (once):
Set-Cookie: sid=8f4e2a91c7b6d05f; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=600

// Browser → server (every later request, automatically):
Cookie: sid=8f4e2a91c7b6d05f

In Express you never hand-write that header. res.cookie(name, value, options) builds it, and the options object is the security surface:

res.cookie('sid', sessionId, {
  httpOnly: true,        // JS can't read it (XSS defense)
  secure:   true,        // HTTPS-only (don't leak over http)
  sameSite: 'lax',       // cross-site send rule (CSRF defense)
  maxAge:   1000*60*10,  // ms in Express (note: raw header is SECONDS)
});

02 The three flags, one at a time

HttpOnly — the anti-theft flag

An HttpOnly cookie is invisible to JavaScript: document.cookie won't show it. That matters because the most common way credentials get stolen is XSS — an attacker injects JS into your page. If your session cookie is HttpOnly, that injected JS still can't read it. This single flag is why session IDs live in cookies and not in localStorage (which is always readable by JS).

Secure — the HTTPS-only flag

A Secure cookie is only ever sent over HTTPS. Without it, a single plain-http:// request (a stray link, a downgrade) leaks the credential in cleartext to anyone on the network. Always true in production. The one exception is local dev on http://localhost — that's why the lab below sets secure:false with a loud comment.

SameSite — the cross-site flag (the CSRF lever)

This one decides whether the browser attaches the cookie when the request originated from a different site. It's the most important and least understood flag, so it gets its own section (§05). Three values:

03 Stop hand-rolling: express-session

For the stateful session design from Lesson 1, you don't set the cookie yourself — the express-session middleware does. You give it cookie options once; it generates the opaque ID, stores the real data server-side, and attaches/reads the cookie on every request. This is the boring, recommended default for an Express web app.

const session = require('express-session');
app.use(session({
  name: '__Host-sid',                 // prefixed credential cookie
  secret: process.env.SESSION_SECRET,    // signs the cookie (tamper-evident)
  resave: false, saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'lax', maxAge: 600000 },
  // store: new RedisStore(...)  ← prod. The default MemoryStore is DEV-ONLY.
}));

app.post('/login', (req, res) => {        // after you've verified the password…
  req.session.userId = user.id;          // truth lives server-side, keyed by the id
  res.redirect('/account');
});

04 🎯 Your tangible win (5 min): run the cookie lab

I've put a tiny, ready-to-run Express app on your machine that sets the same cookie three different ways so you can watch the flags behave. Dependencies are already installed.

# in your terminal:
cd ~/projects/learn/public/courses/auth/practice/cookie-lab
npm start
# → open http://localhost:3000  (DevTools → Application → Cookies)

1. Route / — sets an HttpOnly session id (sid). In the Console run document.cookie → sid is missing. That's HttpOnly working: JS literally cannot see your credential.
2. Route /insecure — sets readable_token with httpOnly:false. Run document.cookie again → now you see it. That's exactly how XSS exfiltrates a credential. Feel the difference one flag makes.
3. Route /samesite — sets a Lax and a Strict cookie. Compare the SameSite column in the Application panel.

05 CSRF: the attack SameSite was built to stop

Here's the problem the automatic-attachment of cookies creates. You're logged into yourbank.com (so your browser holds its session cookie). You visit evil.com. Its page contains a hidden form that auto-submits a POST to yourbank.com/transfer. The browser attaches your bank cookie to that request — because it's going to the bank — even though evil.com triggered it. The bank sees a valid session and processes the transfer. That's Cross-Site Request Forgery.

Note CSRF doesn't need to read anything — the attacker never sees your cookie, they just get it used. That's why HttpOnly doesn't help here, and why CSRF is purely a problem for the cookie (automatic) carrier, not the Authorization: Bearer header (which JS attaches deliberately, so a cross-site page can't replicate it).

The fix, in two layers

06 Production checklist for a credential cookie

Plus: a real session store (not MemoryStore), a sensible maxAge, and a CSRF token on state-changing routes. That's a correctly-shipped session cookie — nothing exotic, just the flags applied deliberately.

07 Check yourself

08 Where we go next

You can now ship the stateful half of Lesson 1 correctly. Next we open the stateless half: JWT anatomy — what those three dot-separated chunks actually are, what "signed" buys you, the infamous alg:none and algorithm-confusion attacks, and when a JWT is the right tool vs a costly mistake. We'll decode a real one in Node.

💬 Ask me anything — e.g. "wire up csrf-csrf in the lab", "show me the Redis store version", or "how does this change for an SPA + API on two domains?" (great question — it's where cookies get genuinely tricky). · Back to Lesson 1 · Resources.