Authentication decides who gets in. Session management decides how long they stay, and it is the half that gets less attention. OWASP maintains a session management cheat sheet because the same problems recur identifiers that survive login, logout that only clears the browser, and cookies that keep working weeks after somebody has left the company.
The identifier itself
A session identifier must be long, random, and issued by the framework rather than invented in-house. It also has to change at the moment privilege changes. If the identifier a user carries before signing in is the same one they carry afterwards, an attacker who can set that value in advance holds an authenticated session as soon as the victim logs in. Rotating on login closes it, and the same applies when a user elevates to an administrative area or completes a second factor. Mainstream frameworks do this correctly by default, so the flaw usually appears where somebody has written a custom login path for a legacy system.
Cookie attributes that do the quiet work
Set Secure so the cookie never travels over plain HTTP, HttpOnly so scripts cannot read it, and SameSite so it is not sent on cross-site requests in a way that enables request forgery. Scope matters as much as the flags: a cookie set on the parent domain is sent to every subdomain, so a vulnerable marketing site on the same domain becomes a route to session theft in your application. Testers check the response headers on the login request specifically, because attributes are often correct everywhere except where the session is first issued.
“The check I run in every web test takes two minutes. Sign in on two browsers, log out of one, then refresh the other. If it still works, your logout is a client-side gesture rather than a security control, and everything you have told users about signing out on shared computers is wrong.”
William Fieldhouse, Director, Aardwolf Security Ltd
Timeouts people can live with
Two timer’s matter. An idle timeout ends a session after a period without activity, and an absolute timeout ends it regardless, which limits how long a stolen cookie stays useful. Fifteen to thirty minutes idle suits banking and administrative interfaces, while a consumer application can be far more relaxed without meaningful risk. Whatever you choose, enforce it on the server. A timer implemented in JavaScript that redirects to a login page leaves the session valid behind the scenes, which testers demonstrate by replaying the cookie after the redirect.
Invalidation when something changes
Ending other sessions is the control users assume they have. A password change, a multi-factor enrolment, an account lockout or an administrator disabling the account should all invalidate existing sessions immediately. Where sessions are stateless tokens, that requires a deliberate mechanism such as short lifetimes with a revocation list, since a signed token is otherwise valid until it expires. A web application security assessment covers these paths by holding several sessions at once, and API testing services do the same for mobile clients, which frequently keeps working long after the browser has been signed out.
Frequently asked questions about session security
These questions come up whenever authentication is being reworked.
Should users see their active sessions?
It is a strong feature for any application holding money or personal data. A list of devices with a revoke button turns account takeover into something the user can end themselves, and it generates useful reports for your security team.
Are remember-me features acceptable?
Yes, with care. Use a separate long-lived token tied to the device, revoke it on password change, and never let it grant access to sensitive actions without re-authentication.
