Session management is how a web application keeps track of a user across multiple requests even though HTTP itself is stateless. These notes cover the session lifecycle, the difference between authentication and authorisation, cookie versus token-based sessions, common weaknesses at each lifecycle phase, and a practical approach to mapping a target application's session behavior.
Web applications do not normally resend your username and password with every request. Instead, after authentication, the application issues a session value that becomes the user's ticket for future actions. If that ticket is predictable, reusable, or insufficiently checked, an attacker may be able to impersonate the user without ever knowing their credentials.
Secure session management therefore has to protect the full lifecycle of the session, not just the login step.
The easiest way to reason about session security is to break it into four lifecycle phases.
Some applications create a session only after authentication, while others create one as soon as the user lands on the site. For authenticated sessions, the important question is how the session value is generated, stored, and handed to the client.
After creation, the session must be attached to each relevant request so the server can map it back to a user and enforce permissions. Problems here often lead to session hijacking, impersonation, or access control failures.
Because HTTP is stateless, the server cannot automatically tell when a user has walked away. Session expiry gives each session a lifetime so that an old session token eventually becomes useless.
When a user logs out, the application should invalidate the session immediately, even if the expiry time has not been reached yet. If logout only removes client-side state but leaves the session valid server-side, an attacker with a copied session may retain access.
Session management becomes much easier to test once the application logic is separated using the IAAA model.
Testing implication: authentication issues often affect session creation, authorisation issues surface during session tracking, and accountability issues become obvious when there is not enough logging to reconstruct what happened during an incident.
Cookie-based sessions rely on the browser's built-in cookie handling. The application sets a session cookie in the response, and the browser decides when to include it in future requests based on domain and cookie attributes.
Set-Cookie: session=12345;Important cookie attributes include:
Token-based sessions shift more responsibility to client-side code. Instead of letting the browser automatically attach a cookie, the application returns a token, often stored in LocalStorage, and JavaScript adds it to requests manually.
A common example is a JWT passed in an Authorization: Bearer header. This model is flexible and useful for distributed applications, but it also removes many of the browser protections that cookies get for free.
Secure, HTTPOnly, and SameSite.If session values are predictable, guessable, or derived from user-controlled input, attackers may be able to create or predict valid sessions. A classic mistake is using something trivial like a base64-encoded username as the session identifier.
If the application trusts client-side token content without properly validating integrity, a user may be able to forge or modify their own session material. This is especially relevant with poorly implemented JWT handling.
If the session identifier is issued before login and not rotated after authentication, an attacker may be able to pre-seed a victim with a known session and then wait for them to authenticate into it.
In multi-application environments such as SSO, session material often moves between services through the browser. Poorly validated redirects or insecure handoff logic can expose session information during that transfer.
Tracking is not just about knowing who the user is. The application also has to verify what that user is allowed to do.
Vertical checks are often handled by route guards or decorators. Horizontal checks are more subtle because the action itself is allowed, but the target record is not. The application must tie the session identity to the requested dataset and verify ownership or scope explicitly.
Without proper accountability, incident response becomes guesswork. Applications should log both accepted and rejected actions, and those logs should preserve enough session context to link actions back to a user.
The main issue here is excessive session lifetime. A session should not remain valid longer than the application's risk profile allows. A banking app should have a much shorter active session than a low-risk consumer portal or mail client.
For long-lived sessions, the application should bind the session to meaningful context such as expected device or location patterns. Large shifts in that context can indicate hijacking and should trigger revalidation or termination.
Logout must invalidate the session server-side, not just remove a cookie or token from the browser. If the server still accepts the session after logout, the user has no reliable way to revoke a hijacked session.
This becomes harder with self-contained tokens whose expiry is embedded in the token itself. In those cases, blocklists or token revocation strategies are required. A strong design also lets users review and terminate active sessions, and resets all active sessions after a password reset.
When testing a target application, the first step is to map the full session lifecycle rather than jumping immediately into exploitation.
Based on the supplied scenario, the session lifecycle mapping exposed several issues and follow-up areas.
| Lifecycle Phase | Observation |
|---|---|
| Session Creation | A combination of cookie and token-based session management is used. |
| Session Creation | A new session value is issued on each login attempt and appears sufficiently random. |
| Session Tracking | Unauthenticated actions are not tracked via a session, but several requests still work without a cookie. |
| Session Tracking | Client-side token values influence what is visible after authentication. |
| Session Expiry | Client-side and server-side expiry behavior do not align, and the lifetime is very long. |
| Session Termination | Logout appears to remove the session, but reusing an old session causes a 500 error instead of a clean invalid-session response. |
At minimum, this would justify reporting excessive session lifetime. It would also justify deeper investigation into API access controls and application logging quality.