Home / Knowledge hub / Session management
Knowledge hub
Session management
How your app creates, tracks, renews and ends a signed-in visit.
What it means
Session management is everything an app does to keep a person recognised after they sign in. HTTP is stateless, so each request must carry something that says "this is the same visit". The server creates that identifier at login, checks it on every request, and ends it at logout or expiry.
It covers more than the cookie. Creation, storage, expiry, renewal, logout, and what happens to old sessions after a password change are all part of the same design. Authentication proves who you are once; session management carries that proof forward.
Why it matters
Weak session handling makes strong passwords pointless. Anyone who steals, guesses or is handed a valid identifier acts as that user. That can mean customer data read, payments made and settings changed, with a log that shows an ordinary signed-in person.
It is also an area with many small ways to fail, and each is easy to miss in a code review. Auditors check it closely, and enterprise buyers often ask for timeout settings and logout behaviour in security questionnaires. Getting it wrong surfaces in both places.
How it shows up
The pieces to check are: an identifier from a secure random source, a fresh one issued at login so a fixed ID cannot be planted, protective cookie flags, idle and absolute timeouts, real invalidation on logout on the server, and revoking sessions when a password or role changes. See session regeneration and logout invalidation.
The mistakes repeat. A logout that only deletes the browser cookie while the server still honours it. The same session ID before and after login. Sessions that never expire. A token placed in a URL. Many sessions allowed with no way to list or end them. Test by replaying an old identifier after logout.
Questions people ask
Session management, answered
What is the difference between authentication and session management?
Authentication is the act of proving identity, usually at login. Session management is how the app remembers that proof across later requests, so the user need not sign in again for each page.
Both can fail separately.
Where should a session identifier be stored?
For a browser app, in a cookie with Secure, HttpOnly and SameSite set, so scripts cannot read it and it is not sent in clear. Avoid putting it in a URL or in local storage.
OWASP recommends cookies for this reason.
What should happen at logout?
The server must end the session on its side, so the old identifier stops working, and the browser cookie should be cleared. Deleting only the cookie leaves a usable token for anyone who copied it.
Test it by replaying the old value.
Server-side sessions or JWTs?
Server-side sessions are easy to revoke but need storage. Signed tokens avoid storage but are hard to revoke before expiry. Neither is automatically safer; it depends on how well each is implemented.
See stateless sessions.
How is session management tested?
A tester checks the identifier's randomness, flags, behaviour at login and logout, timeouts, and whether old or copied sessions still work. They also try fixing an ID before login.
Each failure comes with the request that proved it.
Related
Terms that sit next to this one
Session token
A random value the browser sends to show it belongs to a signed-in visit.
Session timeout
The point at which an idle or old session stops working and sign-in is required again.
Session regeneration
Issuing a new session id at sign-in so an old one cannot be reused.
Logout invalidation
Making sure signing out really kills the session on the server, not just in the browser.
Session fixation
An attacker sets your session id before login, then waits for it to work.
Does a signed-in visit end properly?
We test how your app creates, renews and ends sessions, including what an old token can still do after logout, and each finding comes with the request that proved it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.