Session Timeout

What is a session timeout?

A session timeout is the policy governing how long a user’s authenticated session remains valid before they must re-authenticate. After you log in, the application maintains a session (via a session cookie or token) so you don’t re-enter credentials on every request — but that session shouldn’t last forever, because a live session is a live credential that an attacker who hijacks it can use. The session timeout defines when the session expires, and setting it is a deliberate balance between security and usability: shorter timeouts limit the damage of a stolen or abandoned session but annoy users with frequent logins; longer timeouts are convenient but widen the window of risk.

The two kinds of timeout, and why both matter

There are two distinct timeouts, and good session management uses both. Idle (inactivity) timeout: the session expires after a period of no activity — e.g., log out after 15 minutes of inactivity. This protects against abandoned sessions: a user who walks away from a logged-in computer (a shared or public machine especially) doesn’t leave an indefinitely-open session for whoever sits down next. Absolute timeout: the session expires after a fixed total duration regardless of activity — e.g., a session is valid for at most 8 hours, then you must log in again even if you’ve been active the whole time. This caps the maximum lifetime of any session, so a hijacked session token can’t be used forever — it dies at the absolute limit no matter what. Relying on only one is a common gap: idle-only means an attacker keeping a stolen session “active” can hold it indefinitely; absolute-only means an abandoned session stays open until the (possibly long) absolute limit. Using both bounds the risk from both directions.

Setting it right — context-driven, not one-size-fits-all

The correct timeout depends entirely on the sensitivity of the application and the risk context — there’s no universal number. High-security applications (banking, healthcare, admin consoles, anything handling money or sensitive data) warrant short timeouts (minutes) because the cost of a hijacked session is severe; low-risk consumer apps (a social feed, a media app) can use much longer sessions for convenience, since the stakes of a stale session are low. Related practices sharpen the balance: step-up authentication (re-prompting for credentials or MFA only when the user attempts a sensitive action — a transfer, a settings change — rather than shortening the whole session) lets you keep a convenient general session while protecting high-value operations; and on the token side, the refresh token/access token split achieves a similar effect (short-lived access tokens, longer refresh sessions). Implementation details that bite: sessions must be invalidated server-side on logout (a “logout” that only deletes the client cookie but leaves the session valid server-side is a real vulnerability — a stolen token still works); session identifiers should be regenerated on privilege change (login, elevation) to prevent session fixation; and timeouts must be enforced on the server, not just hinted at the client (client-side-only expiry is trivially bypassed). The recurring mistakes: only implementing one timeout type (idle or absolute, not both), using one blanket timeout regardless of the action’s sensitivity (frustrating users on low-risk actions while under-protecting high-risk ones — step-up auth is the better tool), logout that doesn’t invalidate the session server-side, and enforcing expiry only on the client.

What people get wrong

• Only one timeout type — idle-only lets an attacker hold a “kept-active” stolen session forever; absolute-only leaves abandoned sessions open too long. Use both idle and absolute limits.
• One blanket timeout for everything: forcing short sessions app-wide frustrates users, while long sessions under-protect sensitive actions — use step-up authentication to guard high-risk operations instead.
• Client-side-only expiry and weak logout — timeouts must be enforced server-side, and logout must invalidate the session on the server; otherwise a stolen token keeps working.

Primary source: OWASP Session Management Cheat Sheet