What does weak session management look like, and what does strong session management require?

Weak = session IDs are guessable, client-changeable, long-lived, or not invalidated on logout. Strong = unguessable IDs, server-side invalidation, and properly-attributed cookies.

Signs of weak session management (OWASP A2):

• The session value is predictable (sequential, timestamp-based, low entropy).
• The session value can be set by the client (e.g. Set-Cookie accepted from an attacker's reflection).
• Cookie attributes Secure, HttpOnly, SameSite are not set — IDs leak over HTTP, JavaScript, or cross-site.
• Cookie Domain and Path are wider than necessary — every subdomain has a copy of the session cookie.
• Logout doesn't invalidate the session server-side — just clears the cookie; the old ID still works.
• No absolute or idle timeout — a stolen ID is good forever.

Strong session management:

• Generate IDs with a CSPRNG, at least 128 bits.
• Only accept server-chosen IDs — if the client presents an ID you didn't issue, treat as anonymous.
• Set cookies as Secure; HttpOnly; SameSite=Lax with the tightest possible Domain and Path.
• On logout, on timeout, on password change: delete the server-side session entry. Don't just clear the cookie.
• Apply both an idle timeout (e.g. 15 min for banking) and an absolute timeout (e.g. 24 h max).

Tip: Don't roll your own session store. Use the framework's (Django, Rails, ASP.NET, Spring Security) — they get the boring details right out of the box. Most "weak session" findings in pen-tests come from custom session code, not framework defaults.

Link: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html