Session Management Testing
Test the session lifecycle for weak token entropy, insecure cookie attributes, session fixation, incomplete invalidation, timeout flaws, and remember-me weaknesses.
Tools
Machine-readable JSON available at:
https://reconatlas.pages.dev/api/checklists/session-management-testingTags
// checklist steps
session-01
Analyse session token generation and entropy
Collect a large sample of session tokens and evaluate their randomness and predictability.
# Use Burp Sequencer to capture and analyse 10,000+ tokens for entropy
# Manually sample tokens to spot sequential or timestamp-derived patterns
for i in $(seq 1 20); do curl -sI https://target.com/login -X POST -d 'user=x&pass=y' | grep -i 'set-cookie'; doneWatch for tokens that encode a username, incrementing counter, or Unix timestamp. If the token is a JWT or base64 blob, decode it before assuming it is opaque.
session-02
Check cookie security attributes
Verify that session cookies carry HttpOnly, Secure, an appropriate SameSite value, and a tightly scoped Domain and Path.
curl -sI https://target.com/login -X POST -d 'user=x&pass=y' | grep -i 'set-cookie'
# Confirm HttpOnly, Secure, SameSite=Lax|Strict, and no overly broad Domain=.target.comA missing HttpOnly flag turns any XSS into session theft. A Domain scoped to a shared parent like .target.com leaks the cookie to every subdomain, including ones you may control via subdomain takeover.
session-03
Test for session fixation
Check whether the session identifier issued before authentication is rotated after a successful login.
# 1. Grab a pre-auth session cookie
curl -sI https://target.com/ | grep -i 'set-cookie'
# 2. Authenticate reusing that exact cookie value
curl -si https://target.com/login -X POST -b 'SESSIONID=attacker-fixed-value' -d 'user=victim&pass=victim' | grep -i 'set-cookie'If the post-login response does not issue a fresh Set-Cookie, the session ID is not rotated and fixation is possible. Test both cookie-based and URL-parameter session identifiers.
session-04
Test session invalidation on logout and password change
Confirm that logging out and changing the password server-side invalidate all existing session tokens.
# Capture an active session, log out, then replay a protected request with the old cookie
curl -si https://target.com/account -b 'SESSIONID=old-token-after-logout' | head -n 1
# Repeat after changing the password from a second sessionA token that still works after logout or after a password change is a real finding, especially for account-takeover recovery flows. Test that other devices are logged out when the password changes.
session-05
Test concurrent sessions and timeouts
Assess concurrent-session handling and both idle and absolute session timeouts.
# Log in from two clients simultaneously and confirm policy is enforced
# Idle timeout: leave a session unused, then replay after the stated window
curl -si https://target.com/account -b 'SESSIONID=idle-token' | head -n 1Note the exact idle and absolute lifetimes. A session that never expires, or an absolute timeout measured in months, is worth reporting on high-value applications such as banking or admin panels.
session-06
Test remember-me and persistent tokens
Evaluate the strength, storage, and revocation of long-lived remember-me tokens.
curl -si https://target.com/login -X POST -d 'user=x&pass=y&remember=1' | grep -i 'set-cookie'
# Decode the persistent token; check it is not a predictable user:hash pair
jwt_tool <remember-token> -TRemember-me tokens are often weaker than session cookies. Check that they are single-use or rotated, tied to a server-side record, and revoked on password change and logout.
session-07
Verify CSRF token binding to the session
Confirm that anti-CSRF tokens are cryptographically bound to the user's session and cannot be reused across accounts.
# Capture a CSRF token from account A, then submit it within account B's session
curl -si https://target.com/account/email -X POST -b 'SESSIONID=userB' -d 'csrf=tokenFromUserA&email=x@x.com' | head -n 1A CSRF token accepted regardless of the session it was issued to provides no protection. Also test whether removing the token entirely, or supplying an empty value, is accepted.
Overview
Session management is the connective tissue between authentication and every authorised action a user takes. Even a flawless login can be undermined if the resulting session token is predictable, never expires, survives a logout, or leaks through a badly scoped cookie. This checklist focuses on the session lifecycle and cookie hygiene; JWT internals, OAuth, IDOR, and password-reset flows are covered in the Authentication Testing checklist.
What to look for
- Tokens with low entropy or observable structure (usernames, counters, timestamps)
- Cookies missing
HttpOnly,Secure, or a saneSameSitevalue, or scoped to a shared parent domain - Session IDs that are not rotated on login (fixation) or not destroyed on logout and password change
- Absent or excessively long idle and absolute timeouts, and unbounded concurrent sessions
- CSRF tokens that are not bound to the issuing session
High-impact findings
- Session fixation into account takeover — an attacker pins a known session ID and waits for the victim to authenticate into it.
- Tokens valid after logout or password reset — defeats the primary account recovery control after a suspected compromise.
- Predictable remember-me tokens — long-lived persistent access derived from a guessable value.
// references
- https://portswigger.net/web-security/csrf
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/
- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
- https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- https://portswigger.net/web-security/essential-skills/obfuscating-attacks-using-encodings