ASVS 5.0 V7.3.2 (Level 2) requires an absolute maximum session lifetime. No matter how active the user is, the session ends after that limit and the user must authenticate again. The value follows your risk analysis and documented decisions.
Why it matters
An idle timeout alone can be defeated by activity. A stolen session that is used every few minutes would never expire. The absolute limit caps the damage window, bounds how long stale permissions can persist, and gives you a regular moment to check that the account is still allowed.
How to implement it
Record the creation time when the session starts and never update it. Check it next to the idle timeout.
const ABSOLUTE_MS = 12 * 60 * 60 * 1000;
const IDLE_MS = 15 * 60 * 1000;
function sessionIsValid(s, now = Date.now()) {
if (s.revoked) return false;
if (now - s.createdAt > ABSOLUTE_MS) return false;
if (now - s.lastSeen > IDLE_MS) return false;
return true;
}
For signed tokens, set a fixed exp claim at issue and do not extend it silently. Refresh tokens need their own absolute cap, or a refresh loop becomes an unlimited session.
Choose the value by risk. Twelve hours covers a workday for an internal tool. A high value admin action might get one hour. Write the choice in your session policy.
How to test it
- Create a session, keep it active with requests every few minutes past the limit (adjust the stored creation time to avoid waiting), and confirm it is rejected once the limit passes.
- Verify the response sends the user to sign in, not to an error page.
- Test refresh flows: refresh repeatedly and confirm the chain ends at the cap.
Common mistakes
- Sliding expiry with no ceiling.
- Resetting the creation time when the user does something minor.
- Letting refresh tokens extend forever.
Quick check
How is this different from an inactivity timeout?
Idle timeout measures time since the last request. The absolute limit measures time since sign in and ignores activity.
