After sign-in the session token is the user’s identity; tokens that are predictable, long-lived or never revoked let attackers keep access.
- Generate session tokens on the server with enough randomness, and issue a new one at authentication.
- Enforce inactivity and absolute timeouts.
- End sessions at logout, password change and account disablement.
- Require re-authentication before sensitive changes.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-7.1.1.
V7.1 Session Management Documentation · 3 requirements
V7.1.1 Level 2
Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, and that the documentation includes justification for any deviations from NIST SP 800-63B re-authentication requirements.
V7.1.2 Level 2
Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be taken when the maximum number of active sessions is reached.
V7.1.3 Level 2
Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along with controls to coordinate session lifetimes, termination, and any other conditions that require re-authentication.
V7.2 Fundamental Session Management Security · 4 requirements
V7.2.1 Level 1
Verify that the application performs all session token verification using a trusted, backend service.
V7.2.2 Level 1
Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API secrets and keys.
V7.2.3 Level 1
Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number generator (CSPRNG) and possess at least 128 bits of entropy.
On this site: Session management: cookies, timeouts, rotation and revocation (guide)
V7.2.4 Level 1
Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token.
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Session fixation and session cookies (fix card)
V7.3 Session Timeout · 2 requirements
V7.3.1 Level 2
Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions.
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Session fixation and session cookies (fix card)
V7.3.2 Level 2
Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions.
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Session fixation and session cookies (fix card)
V7.4 Session Termination · 5 requirements
V7.4.1 Level 1
Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tokens or stateful sessions, this means invalidating the session data at the application backend. Applications using self-contained tokens will need a solution such as maintaining a list of terminated tokens, disallowing tokens produced before a per-user date and time or rotating a per-user signing key.
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Case study: the Okta support-system breach and session tokens in HAR files (2023) (guide)
V7.4.2 Level 1
Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company).
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · SCIM deprovisioning: make account disablement remove every usable authority (guide) · Case study: the Okta support-system breach and session tokens in HAR files (2023) (guide)
V7.4.3 Level 2
Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (including password change via reset or recovery and, if present, an MFA settings update).
On this site: Account recovery: password resets, help-desk resets and account linking (guide)
V7.4.4 Level 2
Verify that all pages that require authentication have easy and visible access to logout functionality.
V7.4.5 Level 2
Verify that application administrators are able to terminate active sessions for an individual user or for all users.
On this site: Case study: Citrix Bleed (CVE-2023-4966) (guide)
V7.5 Defenses Against Session Abuse · 3 requirements
V7.5.1 Level 2
Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication such as email address, phone number, MFA configuration, or other information used in account recovery.
On this site: Session management: cookies, timeouts, rotation and revocation (guide) · Case study: the Okta support-system breach and session tokens in HAR files (2023) (guide)
V7.5.2 Level 2
Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions.
V7.5.3 Level 3
Verify that the application requires further authentication with at least one factor or secondary verification before performing highly sensitive transactions or operations.
V7.6 Federated Re-authentication · 2 requirements
V7.6.1 Level 2
Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between IdP authentication events is reached.
V7.6.2 Level 2
Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Session management: cookies, timeouts, rotation and revocation
Model authentication as transitions in server authority, set session cookies and timeouts to current NIST and OWASP values, and verify fixation prevention, expiry, reauthentication, revocation and stolen-cookie defenses.
SCIM deprovisioning: make account disablement remove every usable authority
Connect SCIM resource updates to current sessions, tokens, group-derived permissions and background jobs, with explicit tenant mapping, CAEP revocation events and a measurable revocation contract.
Account recovery: password resets, help-desk resets and account linking
Treat password resets, support-desk recovery and account linking as new grants of authority: single-use high-entropy proofs, atomic consumption, session revocation, and stable identity rather than email matching.
Practice
- Password reset token lab: Make a recovery credential single-use · Browser lab
- Prove deprovisioning reaches sessions and queued work · Local project
References
- V7 Session Management (ASVS 5.0.0 source)
- OWASP Web Security Testing Guide: Session Management Testing
- OWASP Session Management Cheat Sheet
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.