Home / Attacks & tests / Session management testing
8 test cases
Session management testing
Session management testing examines how the application remembers who a caller is between requests: how the session token is generated, transported, bound and destroyed. Authentication happens once; the session is what carries its result, and a weakness here undoes a correct login every time.
What an attacker is trying to achieve
The attacker wants a session belonging to someone else, obtained without their credential — by predicting a token, by fixing one before the victim logs in, by reading one from a place it should never have been written, or by acting through the victim's own browser while their session is live.
Test cases
8 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-SESS-01 Session Management Schema
Objective — Determine whether session tokens are generated, issued and validated in a way that makes one session impossible to derive from another.
How it is tested — Collect a large sample of tokens issued under controlled conditions and examine them for structure, encoded content and sequence. Decode any recognisable encoding to establish whether identity, role or timestamp is carried in the token rather than referenced by it. Determine whether the server validates the token against its own record or trusts its contents, by altering each decoded field in turn and replaying.
Prerequisites — The ability to request many tokens without triggering anti-automation; a proxy; two accounts, so tokens from different principals can be compared.
Indicators — Tokens with visible sequence or shared structure; identity or role recoverable from the token; an altered token still accepted; the same token reissued across logins.
Coverage — WSTG-SESS-01V3.2.1CWE-330CWE-384
Depth — Hybrid Sampling and entropy analysis are automated; deciding what a decoded field means, and which to alter, is manual.
WEB-SESS-02 Cookie Attributes
Objective — Determine whether the cookies carrying session state are constrained so that they cannot be read by script, sent over plaintext, or attached to requests originating from another site.
How it is tested — Record every cookie the application sets across login, privilege change and logout, noting the secure, HTTP-only, same-site, path, domain and expiry attributes of each. Establish which cookies actually carry session state rather than preference, since those are the ones the attributes matter for. Check whether attributes are consistent across all issuing endpoints, and whether a cookie scoped to a parent domain is exposed to sibling hosts outside the application.
Prerequisites — A browser and proxy recording every set-cookie header; the hostname list, to judge domain scoping.
Indicators — A session cookie without secure or HTTP-only; a permissive same-site value on a state-changing application; a cookie scoped to a parent domain shared with unrelated hosts; attributes differing between endpoints.
Coverage — WSTG-SESS-02V3.4.1CWE-1004CWE-614
Depth — Automated Attribute inspection is reliably automated. The judgement is which cookies are session-bearing and whether the domain scope is appropriate.
WEB-SESS-03 Session Fixation
Objective — Determine whether a session identifier established before authentication remains valid after it, allowing an attacker who planted the identifier to inherit the authenticated session.
How it is tested — Obtain a session identifier as an anonymous visitor, then authenticate in the same session and compare the identifier before and after. Repeat for every privilege transition — login, step-up authentication, role change and impersonation — since a token is frequently regenerated at login and then reused across later transitions. Test whether an identifier supplied by the client is accepted rather than replaced.
Prerequisites — An account; a proxy able to set the session identifier before authentication; the ability to observe the identifier at each step.
Indicators — The pre-authentication identifier still valid afterwards; a client-supplied identifier accepted; the token unchanged across a privilege transition.
Coverage — WSTG-SESS-03V3.2.1CWE-384
Depth — Manual Requires controlling the identifier before login, which is a sequence a scanner does not construct.
WEB-SESS-04 Exposed Session Variables
Objective — Determine whether session identifiers or other session state travel or come to rest anywhere they can be read by a third party or retained beyond the session.
How it is tested — Search requests, responses, URLs, referrer headers, redirect targets and client-side storage for the session identifier. Establish whether it appears in any URL, since URLs are logged by intermediaries and leak through referrers to third-party hosts. Examine browser storage and any client-side logging for session material, and determine whether it survives logout.
Prerequisites — An authenticated session; a browser whose storage can be inspected; a page that links or redirects to a third-party host.
Indicators — A session identifier in a URL, referrer or log; session material in browser storage surviving logout; the identifier reflected into a page body.
Coverage — WSTG-SESS-04V3.1.1V8.2.2CWE-598CWE-200
Depth — Hybrid Pattern searching is automated; determining that a value in storage is session-bearing requires knowing what the application does with it.
WEB-SESS-05 Cross-Site Request Forgery
Objective — Determine whether a state-changing request can be caused to succeed by a third-party site acting through an authenticated victim's browser.
How it is tested — For each state-changing operation, remove the anti-forgery token and replay; replace it with a token from another session and with a structurally valid but unrelated value. Establish whether the token is bound to the session, whether it is validated on every method the endpoint accepts, and whether same-site cookie behaviour is the only protection. Reproduce the request as a genuine cross-origin submission rather than a replayed one, since server-side checks may distinguish them.
Prerequisites — Two authenticated sessions to exchange tokens between; a state-changing operation whose effect is observable; a separate origin from which to submit.
Indicators — The operation succeeding with the token absent, altered, or taken from another session; validation applied on one method only; success from a genuine cross-origin submission.
Coverage — WSTG-SESS-05V4.2.2V13.2.3CWE-352
Depth — Hybrid Token-removal tests are automatable; distinguishing a real cross-origin success from a replay, and judging whether the effect matters, is manual.
WEB-SESS-06 Logout Functionality
Objective — Determine whether logging out actually terminates the session on the server, rather than only discarding the client's copy of the token.
How it is tested — Capture an authenticated request, log out, then replay the captured request with the original token. Repeat for every session-bearing artefact the account holds, including API tokens and persistent authentication cookies. Establish whether logout is reachable and effective on every channel, whether it terminates concurrent sessions, and whether browser history navigation re-renders authenticated pages afterwards.
Prerequisites — An authenticated session captured before logout; a proxy able to replay it; a second concurrent session to test whether logout is global.
Indicators — A pre-logout request succeeding afterwards; concurrent sessions unaffected; a persistent token still honoured; authenticated pages re-rendered from history.
Coverage — WSTG-SESS-06V3.3.1CWE-613
Depth — Manual The whole test is a before-and-after replay, which requires the token to be retained across an action designed to invalidate it.
WEB-SESS-07 Session Timeout
Objective — Determine whether an idle or long-lived session expires on the server within a period appropriate to the data it reaches.
How it is tested — Establish a session, leave it idle without any request, and replay a captured authenticated request at increasing intervals to find the point at which it is refused. Separately, keep a session active continuously to establish whether an absolute lifetime exists beyond the idle timeout. Confirm the expiry is enforced on the server rather than by a client-side timer, by replaying outside the browser.
Prerequisites — A non-production environment and enough elapsed time to measure honestly; a captured authenticated request; a client outside the browser.
Indicators — No idle expiry; no absolute lifetime; expiry enforced only by client-side script; a timeout materially longer than the sensitivity of the data warrants.
Coverage — WSTG-SESS-07V3.3.2CWE-613
Depth — Manual Requires real elapsed time and a client that ignores the interface's own timer.
WEB-SESS-08 Session Puzzling
Objective — Determine whether the application reuses one session variable for more than one purpose, so that a value set legitimately in one flow satisfies a check in another.
How it is tested — Enumerate flows that write session state without completing authentication — password recovery, registration, multi-step wizards, guest checkout and impersonation. Begin each, then abandon it part-way and request a protected resource, to determine whether the partially-populated session is treated as authenticated. Compare which variables each flow sets, and look for a variable that both an unauthenticated flow and the authentication check depend on.
Prerequisites — The ability to begin and abandon each flow; a proxy retaining the session across the abandonment; ideally the operator's description of the session model.
Indicators — A protected resource reachable after abandoning an unauthenticated flow; identity established by a flow that never verified it; a recovery flow leaving the session partly authenticated.
Coverage — WSTG-SESS-08V3.2.1CWE-841CWE-287
Depth — Manual Depends entirely on this application's session variable naming and reuse, which no signature describes.
What we need from you
Two accounts and the ability to hold concurrent sessions for both; a proxy retaining every token issued; the ability to observe cookies and storage in a real browser; and a non-production environment where sessions may be left idle long enough for timeout behaviour to be measured honestly.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-SESS-01 — Testing for Session Management Schema
- V3.2.1 — Verify the application generates a new session token on user authentication.
- CWE-330 — Use of Insufficiently Random Values
- CWE-384 — Session Fixation
- WSTG-SESS-02 — Testing for Cookies Attributes
- V3.4.1 — Verify that cookie-based session tokens have the 'Secure' attribute set.
- CWE-1004 — Sensitive Cookie Without 'HttpOnly' Flag
- CWE-614 — Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
- WSTG-SESS-03 — Testing for Session Fixation
- WSTG-SESS-04 — Testing for Exposed Session Variables
- V3.1.1 — Verify the application never reveals session tokens in URL parameters.
- V8.2.2 — Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.
- CWE-598 — Use of HTTP Request With Sensitive Query String
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
- WSTG-SESS-05 — Testing for Cross Site Request Forgery
- V4.2.2 — Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.
- V13.2.3 — Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks.
- CWE-352 — Cross-Site Request Forgery (CSRF)
- WSTG-SESS-06 — Testing for Logout Functionality
- V3.3.1 — Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
- CWE-613 — Insufficient Session Expiration
- WSTG-SESS-07 — Testing Session Timeout
- V3.3.2 — If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.
- WSTG-SESS-08 — Testing for Session Puzzling
- CWE-841 — Improper Enforcement of Behavioral Workflow
- CWE-287 — Improper Authentication
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.