Session Management: What Actually Works
How web applications keep users signed in between requests, using session identifiers or tokens.
Marcus Adeyemi
Why does it matter?
Weak session handling lets attackers hijack accounts, and session bugs cause confusing logouts and data leaks.
What are the numbers?
- Session IDs must be random and long enough to resist guessing
- Cookies session cookies should be HttpOnly and Secure
- Rotation session identifiers should change after sign-in
- Expiry sessions need both idle and absolute timeouts
What should I do?
- Regenerate session identifiers on privilege changes
- Set Secure, HttpOnly and SameSite cookie attributes
- Expire sessions on sign-out everywhere
- Store sessions server-side where practical
- Log unusual session activity
What should I avoid?
Avoid:
- Session identifiers in URLs
- Sessions that never expire
- Reusing identifiers after sign-in
- Sensitive data in client-readable cookies
When should I get help?
Short answer Bring in help when applications handle accounts or payments.
Where this comes from
- OWASP — Session Management Cheat Sheet
- MDN Web Docs — Using HTTP cookies
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
