Endpoint BayISSUE #42 of 45

session cookies · server-managed sessions

RestaVSThe 401 Bandit

Resta saysSession cookies keep auth state server-side — the browser just holds a session id.

The classic web approach: on login the server creates a session, stores state, and sets a cookie with the session id. The browser sends the cookie automatically on each request. Mark it HttpOnly (JS can't read it — blocks XSS theft), Secure (HTTPS only), and SameSite (CSRF defense). Stateful but easy to revoke (delete the session).

Power-ups you unlock

Server stores session; cookie holds the id
Browser sends it automatically
HttpOnly + Secure + SameSite flags
Stateful but trivially revocable

The 401 Bandit attacks — common mistakes

Session cookies without HttpOnly/Secure/SameSite
Sessions that never expire
Storing large state in the cookie itself

Boss battleList the three cookie flags that harden a session cookie and what each blocks.

Example code

<!doctype html><html><head><meta charset="utf-8"></head>
<body style="background:#06040d;color:#e6e0ff;font-family:monospace;padding:20px"><pre>Set-Cookie: sid=abc; HttpOnly; Secure; SameSite=Lax
HttpOnly → blocks JS theft (XSS)
Secure   → HTTPS only
SameSite → CSRF defense</pre></body></html>

▶ Open the interactive comic issue

‹ Refresh Tokens · Keeping Sessions Alive Csrf · Same-Site · Double Submit ›