Session management testing verifies that the tokens keeping a user logged in are unpredictable, transmitted and stored securely, bound to the right user, regenerated at login, and destroyed on logout, timeout and password change. Work through seven areas: cookie flags (HttpOnly, Secure, SameSite), token entropy, session fixation, timeout (idle and absolute), logout invalidation (server-side), concurrent sessions, and JWT pitfalls (weak signing, alg:none, no revocation). Each maps to OWASP WSTG session-management tests. The highest-impact failures are missing cookie flags, fixation, and logout that doesn't kill the session server-side. Full checklist with how-to-test notes below.
// 01 Why session management is high-impact
Authentication proves who you are once; session management is what keeps you trusted on every request after. That makes the session token the crown jewels of a logged-in web app — whoever holds a valid token is that user, credentials or not. It's why session findings so often land as high or critical: a predictable identifier, a token that outlives logout, or a cookie an attacker's script can read all lead to full account takeover. These bugs are also easy to introduce quietly, because an app with broken session handling still works perfectly for honest users. You only see the flaw when someone tests for it — which is the point of this checklist.
// 02 Cookie flags & token entropy
Start with the cookie. A session cookie should carry HttpOnly (so client-side script can't read it, blunting XSS-driven theft), Secure (so it's only sent over HTTPS), and an appropriate SameSite value (Lax or Strict to limit cross-site sending and blunt CSRF). Inspect the response headers directly — don't trust the framework default. Then test entropy: collect a large sample of freshly issued identifiers and check they're long, random and show no pattern, counter, timestamp or encoded username. A token you can predict or increment is game over. Scope: is the cookie's domain and path tighter than the whole site?
// 03 Session fixation & regeneration
Session fixation is the classic: capture the pre-login session identifier, authenticate, and check whether the app issues a new identifier on login. If the same token survives the privilege transition, an attacker who plants a known identifier in a victim's browser inherits their authenticated session. The test is simple and the finding is serious. Confirm the app regenerates the session identifier at every privilege boundary — login, and ideally any step-up such as entering an admin area. While you're here, check that switching users or re-authenticating doesn't silently reuse a stale session.
// 04 Timeout, logout & concurrent sessions
Idle timeout
Leave a session untouched past the stated idle limit — it should expire and force re-auth.
Absolute timeout
Even an active session should have a maximum lifetime, not live forever.
Logout invalidation
After logout, replay the old token — it must be dead server-side, not just cleared in the browser.
Password change
Changing or resetting the password should invalidate existing sessions elsewhere.
The trap here is a logout that only clears the cookie client-side while the session stays valid on the server — capture a token, “log out,” replay it, and if it still works you've found a real vulnerability. Also test concurrent sessions: does the app allow, cap, or notify on multiple simultaneous logins, and does it match its own stated policy?
// 05 JWT-specific pitfalls
If the app uses JWTs, the checklist shifts. Because JWTs are usually stateless, revocation is the hard problem — there's often no server-side session to destroy, so a stolen token stays valid until it expires. Test the signing algorithm: the server must reject alg:none and resist algorithm-confusion (e.g. an RS256 verifier tricked into treating the public key as an HMAC secret). Confirm the signature is actually verified (tamper with the payload and check it's rejected), that expiry (exp) is enforced, and that there's a revocation or short-lifetime-plus-refresh strategy so a leaked token isn't valid for hours. Never trust claims in an unverified token.
// 06 Grading & reporting the findings
When you find a session flaw, grade it on exploitability and impact, not on a generic label. A missing HttpOnly flag on a site with no XSS is lower risk than a fixation bug or a non-invalidating logout, which lead directly to account takeover. Chain where you can — a readable session cookie plus a reflected XSS is a full compromise, and that chain belongs in the report as one high-severity story, not two mediums. Reproduce each finding with the exact request/response evidence, and give a concrete fix. That's the difference between a scan line item and a report your team can act on — the standard set out in our methodology.
// 07 Frequently asked questions
What is session management testing?
It checks how a web app creates, maintains and destroys the tokens that keep a user logged in — verifying identifiers are unpredictable, transmitted and stored securely, bound to the user, regenerated at login, and invalidated on logout, timeout and password change. Weak session management is high-impact because a stolen token lets an attacker act as a real user without credentials.
What are the most common session vulnerabilities?
Missing HttpOnly/Secure/SameSite cookie flags; identifiers with weak entropy or a predictable pattern; session fixation (no regeneration after login); sessions that never expire or ignore idle timeout; logout that doesn't invalidate server-side; and JWTs with weak signing, alg:none acceptance, or no revocation. Each enables session hijacking or extension.
Does logout have to invalidate the session server-side?
Yes. A logout that only clears the browser cookie but leaves the session valid server-side is a real vulnerability — anyone who captured the token can keep using it after the user thinks they've logged out. Proper logout destroys the session server-side, and a password change or reset should invalidate existing sessions too.
Are JWTs harder to test?
They have different pitfalls. Being stateless, revocation is the hard part — a stolen token stays valid until expiry. Testing focuses on the signing algorithm (rejecting 'none' and confusion attacks), signature verification, expiry, and whether a revocation or short-lifetime-plus-refresh strategy exists. Server-side sessions are easier to revoke but need the classic cookie and fixation checks.
// 08 Related reading
- Web application penetration testing — where this checklist runs.
- OWASP Top 10 in real engagements and the tools we use.
- Our penetration testing methodology and mass assignment.