Set Session Idle and Absolute Limits
Set server-enforced idle and absolute session limits, then test renewal, expiry, reauthentication, and revoked access.
A session can remain active long after the user leaves a device. An idle timeout limits inactivity; an absolute limit ends a session even if it stays busy. These are different controls and should be enforced by the server, not only by a browser timer. OWASP's session guidance describes session lifetime and reauthentication considerations.
Choose limits for the application's risk and normal workflow. A short limit may disrupt a long support task; a long limit may leave privileged access open. Write down when activity resets the idle clock, which actions require fresh authentication, and whether an upstream SSO session can create a new application session.
Session state table
| State | Event | Expected result |
|---|---|---|
| Active | Valid request within idle window | Continue after authorization |
| Idle expired | Request after inactivity | Reauthenticate |
| Absolute expired | Request despite continuous use | Reauthenticate |
| Role changed | Old privileged request | Deny or refresh authority |
| Logged out | Reuse old cookie | Deny |
| Clock uncertain | Server time differs | Follow bounded policy |
Store expiry state where the application can enforce it. A client-side warning can help the user save work but must not extend the server deadline. Reauthentication should use a trusted flow and not simply accept a still-valid old session cookie as proof.
Time-bound test
In an owned test environment, set short test limits. Make one request before the idle deadline, then wait past it and require a new sign-in. Keep a separate session active until the absolute deadline and confirm it still expires. Test a long-running upload or background task so the product handles interruption deliberately. Finally, log out and replay the old session identifier.
Record the configured values, server times, response classes, and user-facing behavior. Do not capture real cookies in test reports. A session limit does not revoke a copied API key. Check SSO and refresh-token behavior separately; one provider may silently issue a new application session. Revisit the limits when the app adds high-impact actions or changes identity providers.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.
Sources
- OWASP Session Management Cheat SheetAccessed
- NIST SP 800-63BAccessed