Checklist

OWASP session management checklist

A checklist based on the OWASP Session Management Cheat Sheet. Use this when reviewing how sessions, cookies, and tokens are issued, transmitted, and revoked.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

34 items
7 sections
Reusable template

Your progress

0 of 34 items complete

complete

Saved in your browser. Sign in to Checksy to share progress with your team.

Session token generation

Session IDs are produced by the framework's vetted generator
Session IDs are at least 128 bits of entropy
Session IDs carry no meaning (no encoded user ID, role, etc.)
A new session ID is issued on every privilege change
Session IDs are rotated immediately after authentication

Cookie attributes

`Secure` attribute is set on every session cookie
`HttpOnly` attribute is set to block JS access
`SameSite` is set to `Lax` or `Strict` as appropriate
`Domain` is set as narrowly as possible
`Path` is set to `/` only when needed; otherwise scoped down
No session data is stored in non-`HttpOnly` cookies

Session lifetime

An idle timeout is enforced server-side (e.g., 15–30 min for sensitive apps)
An absolute timeout is enforced regardless of activity
Session expiry is checked on every request, not only at login
Long-lived "remember me" cookies use a separate, revocable token
Concurrent session limits are configurable per account

Session termination

Logout invalidates the session on the server, not only the cookie
Logout is reachable from every authenticated page
Password change, MFA reset, or role change invalidates other sessions
Users can list and revoke active sessions from their account page
Tokens revoked on the server are rejected immediately, without grace

Cross-site request protection

State-changing requests require an anti-CSRF token or `SameSite` cookie
Anti-CSRF tokens are tied to the user session
CORS policy lists only the origins that need access
`Origin` and `Referer` headers are checked on sensitive endpoints

Token-based sessions (JWT, opaque)

Tokens are signed with a strong algorithm; `alg: none` is rejected
Signing keys are stored in a KMS or secrets manager
Tokens have a short expiry; refresh tokens are single-use
Sensitive data is not placed in JWT claims
A revocation list or short-lived access token strategy is in place

Transport and storage

All session traffic is over TLS; no fallback to HTTP
HSTS is enabled with a long max-age
Session IDs do not appear in URLs, logs, or referrers
Browser storage (localStorage, sessionStorage) is not used for tokens

Run this checklist for real

Save your progress, share with your team, and turn this into a reusable template. This helps you track how you improve over time.

Use in Checksy More checklists