Home / Knowledge hub / Session timeout
Knowledge hub
Session timeout
The point at which an idle or old session stops working and sign-in is required again.
What it means
A session timeout is the rule that ends a signed-in session and forces a fresh sign-in. There are two kinds. An idle timeout ends the session after a period of no activity. An absolute timeout ends it after a set total time, however busy the user has been.
The time must be enforced by the server. A browser cookie that expires on the screen but is still accepted by the server only looks like a timeout. The length of each limit should also match the risk of what the account can do.
Why it matters
Time limits shrink the window in which a stolen or forgotten session is useful. A laptop left open in a café, a shared computer, or a cookie copied from a log are all less dangerous if the session ends in minutes. Without limits, one theft can be used for months.
It is a common line in security questionnaires and audits. OWASP suggests idle timeouts of 2 to 5 minutes for high-value applications and 15 to 30 minutes for lower-risk ones. Missing or very long timeouts weaken what session hijacking can achieve.
How it shows up
Check three things: that both an idle and an absolute limit exist, that the server enforces them rather than the page, and that sensitive actions such as changing a password or payment details ask for a fresh sign-in. Sliding sessions extend the idle limit and need an absolute cap beside them.
The mistakes repeat. "Remember me" cookies that never expire and carry full rights. Refresh logic that keeps extending a token forever. A timeout set in the front-end that the server ignores. Long-lived API tokens used as browser sessions. Test by waiting past the limit and then replaying the old identifier.
Questions people ask
Session timeout, answered
What is the difference between idle and absolute timeout?
An idle timeout counts from the last request; each action resets it. An absolute timeout counts from login and does not reset. Having both stops a session staying alive for ever through steady use.
Good practice is to use both.
How long should a session timeout be?
It depends on what the account can do. OWASP gives 2 to 5 minutes idle for high-value apps and 15 to 30 minutes for low-risk ones, as examples. Absolute limits are usually hours, not days.
Choose by risk, not by convenience.
Does a timeout in the browser count?
Only as a courtesy. The server must refuse the expired session on its own; otherwise a copied token keeps working.
If someone replays an expired identifier and it works, the timeout is not real.
Do API tokens need timeouts?
Yes. Access tokens should be short-lived, and long-lived credentials should be limited, rotated or revocable. A token that never expires turns a single leak into a permanent breach.
See JWT expiry.
How do we test the timeout?
Sign in, note the session identifier, wait past the stated limit without activity, and replay it. Then repeat after a long, busy session to check the absolute limit.
A working request after expiry is a finding.
Sources
Where this comes from
Related
Terms that sit next to this one
Sliding session
A session whose expiry is pushed back each time the user is active.
Session management
How your app creates, tracks, renews and ends a signed-in visit.
JWT expiry
The time claim that stops a signed token from being accepted forever.
Remember me
A long-lived login option, and the extra risk it carries if its token is stolen.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Does an old session really stop?
We replay session values after the point they should have expired, and report only the ones the server still accepted, with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.