How to test session expiry properly

Sessions are the thing that keeps you logged in between requests, and "keeps you logged in" is exactly the behaviour that goes wrong. A session that lives too long is a security hole; one that dies too soon loses people's work; one that survives logout means a shared or stolen session never really ends. None of this needs tooling to test — just patience, a clock, and a second tab. It's the natural companion to the password reset bugs I always test for and the broader auth pass.

Know the policy before you test

Ask (or find in the spec): how long should a session last idle? How long absolutely, regardless of activity? Does "remember me" extend it, and by how much? Without the intended numbers you can only spot the egregious failures. With them, every check becomes "does the actual behaviour match the stated policy?"

1. Idle timeout

Log in, do nothing past the idle limit, then act. You should be logged out (or re-challenged), not sailing straight through. The subtle failure: the timeout resets on background activity (polling, analytics pings) so the session never actually goes idle from the server's view, and the user is effectively never logged out. Watch for "idle" that isn't.

2. Absolute timeout

Separate from idle: even an actively-used session should eventually expire and force re-authentication (common for anything sensitive). Stay active past the absolute limit and confirm you're re-challenged. Many apps only implement idle timeout and have no absolute cap — worth flagging.

3. Logout actually ends the session

The big one. Log in, capture a working request (or just keep a tab open), then log out. Now replay the old session — resend the request, or use the still-open tab. If it works, logout only cleared the client (cookie/localStorage) and the server-side session is still valid. A logout that doesn't invalidate server-side means a copied session token outlives the logout — exactly what logout is supposed to prevent.

4. Password change / reset invalidates other sessions

Keep a session open in one browser, change the password (or complete a reset) in another, then use the first. It should be dead — the whole point of a password change is often that the account was compromised. Frequently it isn't, and the attacker's session sails on. Same test for an explicit "log out all devices."

5. "Remember me" behaves as claimed

Tick "remember me" and confirm the session really does persist as long as advertised — and, crucially, that unticking it gives a genuinely shorter session. A "remember me" that's always on regardless of the checkbox is a quiet bug.

6. Concurrent and fixation edges

• Concurrent sessions: if the policy is one session per user, does logging in elsewhere kill the first? If multiple are allowed, do they expire independently?
• Session fixation: does the session identifier change on login? If the pre-login token is still valid after authenticating, a fixed/planted token can be reused — a classic, testable flaw (the token before and after login should differ).

Reporting

Test data and authorised accounts only; report behaviour vs policy: "session still valid 30 min after logout; expected immediate server-side invalidation." The security testing checklist covers the full QA-safe auth pass.

Session expiry pass

• Idle timeout fires — and isn't silently reset by background polling
• An absolute timeout exists and forces re-auth even on active sessions
• Logout invalidates the session server-side (replayed old session fails)
• Password change / reset and "log out everywhere" kill existing sessions
• "Remember me" persists as advertised; unticking it genuinely shortens the session
• Session ID changes on login (no fixation); concurrent-session policy is enforced