Session Management Security: Cookies, Tokens and Timeouts

After a user logs in, the session is what keeps them logged in. If an attacker can steal, guess, fix or reuse that session, they never need the password.

Cookie-based sessions: the right flags

If you use cookies for sessions, set these attributes:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/

• HttpOnly stops JavaScript from reading the cookie, limiting the damage of XSS.
• Secure sends the cookie only over HTTPS.
• SameSite=Lax or Strict blocks most cross-site request forgery.
• Scope narrowly. Avoid setting a Domain attribute that shares the cookie with every subdomain unless needed.

Session fixation

In session fixation, the attacker sets a known session ID in the victim's browser before they log in, then uses the same ID afterwards. Fix: always issue a new session identifier at login and when privileges change.

Token-based sessions and JWTs

Single-page apps often use tokens such as JWTs. Common pitfalls:

• Storing tokens in localStorage, where any XSS can read them. Prefer HttpOnly cookies, or keep access tokens short-lived and in memory.
• Long-lived access tokens that cannot be revoked. Use short expiry with refresh tokens.
• Refresh tokens that never rotate. Rotate on each use and detect reuse.

Expiry and timeouts

Sessions should end. Typical settings:

Choose based on risk, and let enterprise customers configure stricter values where possible.

Invalidation

Sessions must be invalidated:

• On logout, server-side, not just by deleting the cookie.
• After password change or reset.
• When a user is removed from an organisation or their role changes.
• When an admin revokes access or the user clicks "log out of all devices."

Stateless JWTs make this hard. Keep a revocation list, use short-lived tokens, or check a session version on each request.

Session IDs must be unpredictable

Use your framework's built-in session generation, which uses cryptographically secure randomness. Never build session IDs from user IDs, timestamps or hashes of predictable data.

Testing session management

Testing checks cookie flags, regeneration at login, logout invalidation, token expiry, reuse after password change and access after removal from a team. SecurityInfinity agents run these checks in authenticated tests and flag weaknesses with fixes. Start free.

Frequently asked questions

Are JWTs less secure than session cookies?

Not inherently, but they are easier to misuse, especially around storage and revocation. Many apps are simpler and safer with server-side sessions.

Should sessions be bound to IP address?

Strict IP binding breaks for mobile users. Detecting suspicious changes, such as a new country, and requiring re-authentication is a better balance.

How long should a remember-me token last?

Weeks at most, rotated on use, revocable, and never sufficient for sensitive actions without re-authentication.