How do you test session management — what signals indicate a problem?

Session token properties to validate:

1. Unpredictability: capture several session tokens and verify they have high entropy — long random strings, not sequential IDs or predictable patterns derived from user data.

2. New token on login (session fixation prevention): before logging in, note the session cookie value. After successful authentication, the session cookie must be a different value. If the same cookie is retained, an attacker who pre-set a session cookie could "fix" a victim's session.

3. Inactivity timeout: log in, wait without interacting for the configured timeout period (e.g. 15 minutes), then attempt a request. The response should be 401 or a redirect to login — not a successful response.

4. Absolute timeout: even if the user is continuously active, the session should expire after an absolute maximum (e.g. 8 hours for a corporate app). This prevents indefinitely-valid sessions from stolen tokens.

5. Logout invalidation (server-side): log in, capture the session token, log out, then replay a request using the old token. The response must be 401. If the old token still works, logout is client-side only (cookie deleted in the browser, but token still valid on the server) — a serious vulnerability.

6. Concurrent sessions: depending on policy, logging in from a new device should either invalidate previous sessions or at minimum notify the user.

Token storage check: the session token should be in an HttpOnly, Secure, SameSite cookie — not in localStorage or a URL parameter, where it's vulnerable to XSS or logging.