Session Management Testing

Why it matters

To the server, whoever sends a valid session identifier is the signed-in user, with no password and no second factor. A predictable, planted, leaked or never-ending identifier therefore turns a strong login into a weak one.

These defects never show in functional testing, because the user's own journey works. Only tests designed for them find them, and most are cheap: two browser profiles, developer tools and a test account. The OWASP Web Security Testing Guide (WSTG) has a whole category of session management tests; this lesson turns its core ones into test conditions you can run on every release.

The session lifecycle as a state model

In the lesson on cookies and sessions over HTTP you traced one session by hand. A security test plan must cover every way a session starts, changes and ends, and a state model, as in state transition testing, makes that visible: no session, an anonymous session (many applications create one before login), signed in, idle, and ended. Each transition is a test condition.

One rule covers the whole model: at login, at every privilege change and at every way a session ends, the old identifier must stop working on the server; only the moves between signed in and idle keep the same identifier. The check is always the same: keep a copy of the old identifier, replay it after the transition, and expect the login page or 401, never the user's data. The expected values, such as both timeouts and the events that end other sessions, come from the team's session policy.

Try it: State Transition Generator

Identifier randomness: look for structure

The OWASP Session Management Cheat Sheet asks for identifiers from a cryptographically secure random generator with at least 64 bits of entropy; version 5.0 of the OWASP Application Security Verification Standard (ASVS) asks for at least 128 bits, so use the minimum your team's policy adopts. You cannot prove randomness by looking, but you can find the structure that disproves it. Log in about 20 times with one test account and a few times with another, record each identifier with its time, and line them up.

• Length gives only an upper limit: 32 hexadecimal characters carry at most 128 bits. If 24 of them never change, the other 8 carry at most 32 bits, below the minimum.
• A prefix that every value shares, or a part that grows by one at each login, is a counter, not randomness.
• Decode the value as Base64 and convert long numbers as Unix timestamps (seconds or milliseconds since 1 January 1970 UTC): a user id, an email or the login time inside means the identifier is built, not random.
• A second login by the same user must give a completely different value, and the identifier must never appear in URLs, page source or error messages.
• These checks find structure but cannot prove its absence. Statistical analysis of a large sample, for example with the Sequencer in Burp Suite, is specialist work; the best evidence is that the framework's built-in session manager creates the identifier, which OWASP recommends over a home-made one.

Try it: Base64 Decoder Try it: Timestamp Converter

Worked example: testing session fixation

In session fixation the attacker plants an identifier instead of stealing one: they obtain a valid pre-login identifier, get it into the victim's browser, for example through a link that carries it in the URL or a cookie set from a sibling subdomain, and wait for the login. If the application keeps that identifier, the attacker's copy is now signed in.

Set-up: a staff portal, https://hr.example, in a test environment, one test account and two browser profiles, A for the attacker and B for the employee. Test only systems you own or have written permission to test. The trace shows A's visit, B's login after the cookie was set by hand, and A's replay.

• In A, open the login page and copy the pre-login sid. In B, set sid to that value in the storage panel of the developer tools, then log in.
• Expected: the login response sets a new sid, and reloading /dashboard in A leads to the login page. If A sees the employee's dashboard, the session is fixed: propose critical severity.
• Repeat with a value the server never issued, such as sid=tester-made-0001. A strict session manager ignores it and issues its own; OWASP calls one that accepts it permissive. Report that even if renewal still protects the login.
• Repeat at every privilege change: re-authentication before a sensitive action, a switch of role or organisation, and another user logging in on the same browser. When the session travels in a cookie, an identifier in the URL, such as ?sid= or ;jsessionid=, must be ignored.

GET /login HTTP/1.1
Host: hr.example

HTTP/1.1 200 OK
Set-Cookie: sid=Pq7Lm2Vx9Rt4Kw8N; Path=/; Secure; HttpOnly; SameSite=Lax

POST /login HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

HTTP/1.1 303 See Other
Location: /dashboard
Set-Cookie: sid=Zc4Hn8Tq1Wy6Bd3F; Path=/; Secure; HttpOnly; SameSite=Lax

GET /dashboard HTTP/1.1
Host: hr.example
Cookie: sid=Pq7Lm2Vx9Rt4Kw8N

HTTP/1.1 302 Found
Location: /login

Try it: cURL Generator

Timeouts and logout: every way a session must end

You already test both timeouts with boundary values and replay the identifier after logout. At security level, also test what keeps a session alive by accident and every event that should end one. Note the time of each request: the server's clock decides, not the page.

• Background traffic: leave a page that polls the server, such as a notification counter, idle past the limit. If polling counts as activity, the session never idles out; ask whether that is intended.
• Warning dialogs: "Stay signed in" must extend the session on the server, and ignoring the warning must end it there, not only hide the page. No activity extends the absolute timeout.
• Tabs and devices: logout in one tab ends the session in every tab, and "Log out of all devices" also ends the session in a second browser profile.
• Password change: the ASVS expects an option to end all other sessions after a change of any authentication factor, such as a password change, including one made through password reset, or an update of the MFA settings. It also expects every session of a disabled or deleted account to end; ask what the policy says about removed roles.
• Every credential: a remember-me cookie (a persistent cookie that signs the user in again without the password), a refresh token (a long-lived token that obtains new access tokens) or the access token of a single-page app must also stop working at logout. Replay each one.
• After logout the Back button may redisplay a page from the browser's history. That is a caching question; reload or click anything, and the server must answer with the login page.

Cookie flags on every session cookie

You know the baseline for a session cookie: Secure, HttpOnly, an explicit SameSite, no broad Domain and no Expires or Max-Age. The security question is coverage: does every cookie that can act as the user meet it, on every response that sets it?

• Cookies with session power: the session identifier, a remember-me cookie, a refresh token kept in a cookie, and any second session cookie from another framework or a single sign-on component.
• Responses that set them: login, renewal after a privilege change, a token refresh and a "remember me" login. A renewal written by other code can drop attributes.
• Name prefixes: browsers accept a cookie named __Host-sid only from an HTTPS page with Secure, Path=/ and no Domain, and a __Secure- cookie only from an HTTPS page with Secure. A response that drops an attribute is then rejected, so the defect shows up as an unexpected logout. __Host- also stops a sibling subdomain from planting the cookie, which closes one fixation route.
• A test environment without HTTPS cannot show Secure working; check once in an environment configured like production.
• Flags reduce theft and misuse of the cookie; they do not fix a predictable identifier, a missing renewal or a logout that leaves the server session alive.

Try it: Cookie Analyzer

Frequently asked questions

References

• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Cheat Sheet Series: Session ManagementOWASP FoundationSession identifier entropy, cookie attributes, expiry, renewal after login and logout handling.
• OWASP Application Security Verification Standard (ASVS)OWASP FoundationA checklist of verifiable security requirements for web applications, grouped in three assurance levels.
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)Cookie lifetime, scope, the Secure/HttpOnly/SameSite attributes and their security implications.