Cookies, session tokens, secure flags, rotation after login. How servers bind an authenticated user to a browser — and how session fixation, predictable tokens, and missing HttpOnly break that binding.
Session management is the mechanism by which a server maintains state across stateless HTTP requests. After authentication, the server issues a session token — typically stored in a cookie — that the browser sends with every subsequent request. How that token is generated, stored, transmitted, and invalidated determines whether the session can be stolen or forged.
HTTP is stateless — each request carries no memory of previous requests. To remember that a user has logged in, the server issues a session token, a random string stored in a cookie. The browser sends it automatically on every request, and the server looks it up in its session store to determine the user's identity and permissions.
The security of this system depends entirely on keeping the token secret. If an attacker can steal or predict the token, they can impersonate the user without knowing their password. Cookie flags — Secure, HttpOnly, and SameSite — are the standard defences that gate different attack vectors.
The sandbox below simulates a browser DevTools-style cookie inspector. You can toggle Secure, HttpOnly, and SameSite flags on a session cookie and immediately see whether three common attacks — XSS cookie theft, Man-in-the-Middle sniffing, and Cross-Site Request Forgery — succeed or fail against your chosen configuration.
In 2016, a security researcher discovered a session fixation vulnerability in Slack. The attacker could craft a link containing a pre-set session ID:https://slack.com/login?session_id=ATTACKER_SET_ID. If the victim clicked the link and logged in, Slack would reuse the attacker-supplied session ID instead of generating a new one after authentication. The attacker already knew the session ID and could hijack the session immediately after login.
The fix was straightforward: regenerate the session token on the server after every successful login — a practice called “session rotation”. Slack also added HttpOnly and Secure flags to their session cookie to prevent XSS-based theft and MitM sniffing. The case remains a textbook example of why a single missing flag or rotation step can undermine the entire authentication system.
Three defences work together to protect session tokens. Cookie flags control what the browser does with the token. Session rotation ensures that a stolen pre-authentication token cannot be used after login. Server-side binding ties the token to specific client attributes.
// VULNERABLE - missing flags and no rotation
res.setHeader('Set-Cookie', `session=${token}; Path=/`);
// No Secure — sent over HTTP
// No HttpOnly — readable by JavaScript
// No SameSite — sent on cross-origin requests
// SAFE - flags + rotation after login
app.post('/api/login', async (req, res) => {
const user = await authenticate(req.body);
if (!user) return res.status(401).end();
// Regenerate token after login (prevents fixation)
const newToken = crypto.randomBytes(32).toString('hex');
await sessionStore.create(newToken, user.id);
res.setHeader('Set-Cookie', [
`session=${newToken}; Path=/;`,
'HttpOnly;', // blocks document.cookie
'Secure;', // TLS only
'SameSite=Lax', // blocks CSRF from external sites
'Max-Age=86400', // 24h expiry
].join(' '));
res.json({ ok: true });
});
// SAFER - bind session to client fingerprint
app.use((req, res, next) => {
const token = parseCookie(req, 'session');
const session = await sessionStore.get(token);
if (session && session.fingerprint !== fingerprint(req)) {
sessionStore.destroy(token);
return res.status(401).end();
}
next();
});Additional measures: set short session expiry times, invalidate sessions on password change, store sessions server-side rather than in JWTs where revocation is impossible, and consider binding sessions to a client fingerprint (IP + User-Agent hash) as a defence-in-depth layer.
1.Which cookie flag prevents JavaScript from reading the session token via document.cookie?
2.What is session rotation and why is it necessary?
3.An application sets Set-Cookie: session=abc123; Path=/; Secure. What attacks is it still vulnerable to?