IAM-012 Session Management
Description
User and application sessions are subject to defined management controls: sessions time out after a defined period of inactivity, concurrent session limits are enforced where appropriate, and session identifiers are protected against fixation and hijacking. Re-authentication is required after sensitive operations or extended inactivity.
Rationale
Unmanaged sessions allow attackers to hijack abandoned authenticated sessions. Session controls reduce the window of opportunity for session-based attacks.
Framework Mappings (4)
| 8.5 | Secure authentication | informative |
| AC-11 | Device Lock | partial |
| AC-12 | Session Termination | full |
| IA-11 | Re-authentication | full |
Evidence (2)
Application and IdP session management configuration showing idle timeout, absolute session lifetime, and re-authentication settings.
Example: Okta session policy export or application-level session configuration (e.g. express-session or Django SESSION_COOKIE_AGE settings in a config file, or Okta admin GET /api/v1/policies?type=OKTA_SIGN_ON) showing idle timeout ≤ policy limit, max session lifetime, and re-authentication triggers.
Test: Query the IdP session policy and a sample of application session configurations. Verify: (1) idle timeout is set to a value ≤ the policy maximum (commonly 15–30 minutes for sensitive systems), (2) an absolute maximum session lifetime is enforced, (3) re-authentication is required after the idle timeout or before sensitive operations as defined in policy, (4) concurrent session limits are configured where the platform supports it.
Application security scan or DAST report confirming that session identifiers are protected against fixation, are invalidated on logout, and are not exposed in URLs.
Example: OWASP ZAP, Burp Suite, or equivalent DAST scan report for the production application showing no high/critical findings for CWE-384 (Session Fixation), CWE-613 (Insufficient Session Expiration), or CWE-598 (Use of GET Request Method with Sensitive Query Strings).
Test: Review the most recent DAST or security scan report covering the production application. Verify: (1) report was run against the current production or pre-production build, (2) no open high/critical findings relate to session management vulnerabilities, (3) any medium findings have a documented risk acceptance or remediation ticket with a target date.
Questions (2)
Are session management controls enforced, including idle timeout, absolute session lifetime limits, and session identifier protection?
Controls must be enforced at the system level — not left to the end user to configure. Session identifiers must not appear in URLs and must be invalidated upon logout.
What is the maximum idle session timeout configured for users accessing production systems?
15–30 minutes is the expected range for production and administrative systems. Timeouts above 60 minutes or no timeout configured are findings for sensitive environments.