Session security: why "stay logged in" needs care
What a session is, how it can be stolen or abused, and the settings that let users stay logged in without leaving the door open.
The short answer
When a user logs in, the application gives their browser a session token, usually in a cookie, and from then on that token is what proves who they are on every request. The password is not checked again; the token is. Whoever holds the token is the user, which is why session security matters as much as login security and is thought about far less. Tokens are stolen through scripts injected into pages, cookies sent over insecure connections or readable by scripts, shared or unattended devices, and tokens that never expire and cannot be revoked. Safe sessions use cookies with the flags that make the browser protect them, expire after a sensible time and after inactivity, are renewed on login and on any change of privilege, and can be listed and revoked by the user and by the business. Offering stay logged in is fine when it is a limited, device-bound, revocable token for everyday use, with a fresh login required for sensitive actions.
How sessions go wrong and how they are protected
| Threat | How it works | Protection |
|---|---|---|
| Script injection reads the cookie | An injected script sends the token elsewhere | HttpOnly flag so scripts cannot read it; content security policy; output escaping |
| Cookie sent over an insecure connection | Intercepted on the network | Secure flag; HTTPS everywhere; HSTS |
| Cross-site request abuse | Another site triggers actions using the logged-in cookie | SameSite attribute; anti-forgery tokens on state-changing requests |
| Token fixed before login | Attacker sets a known token, user logs in with it | New token issued on every login and privilege change |
| Token never expires | Stolen months ago, still valid | Absolute and inactivity timeouts; renewal on use |
| No way to revoke | User cannot recover from theft | Server-side session store; sign out everywhere; revoke on password change |
| Shared device | Next person is still logged in | Inactivity timeout; clear sign-out; fresh login for sensitive actions |
| Guessable token | Predictable identifiers | Long random tokens from a proper generator |
Building sessions properly
- Generate long random tokens and store session state on the server so tokens can be revoked.
- Set the cookie flags: HttpOnly, Secure, SameSite, a tight path and domain.
- Issue a new token on login, on logout and whenever privileges change.
- Expire after an absolute period and after inactivity, with the periods matched to the risk of the application.
- Implement stay logged in as a separate, device-bound, revocable token that only restores recognition.
- Require a fresh login for sensitive actions: changing credentials, viewing payment data, exporting, administrative changes.
- Give users a session list with sign out everywhere, and revoke all sessions on password change.
- Log logins, logouts, revocations and unusual patterns such as one session from two countries.
What users notice
Almost nothing, which is the point. They stay recognised on their own device, they are asked to log in again before something sensitive, they can see where they are logged in and end it, and if they change their password everything else signs out. The experience is smoother than an application that logs them out every hour and less dangerous than one that never does.
What this means for you
A session token is the user for as long as it lives, so protect it like a password: cookie flags set, new token on login, sensible expiry, a separate revocable token for stay logged in, fresh login for sensitive actions, a session list with sign out everywhere, and logging. Those settings let users stay logged in comfortably without an injected script or a shared laptop becoming an account takeover.
Frequently asked questions
If the password is strong, why does the session matter?
Because after login the password is not used again; the session token is. A token stolen through an injected script, an insecure cookie or a shared device gives the attacker the account without the password or the second factor. Session security is what protects the account for the hours or weeks after the login, which is most of the time.
Is offering stay logged in a bad idea?
Not if done properly. A long-lived token can be limited to keeping the user recognised, with sensitive actions such as changing the email address, viewing payment details or exporting data requiring a fresh login. The token is tied to the device, expires after a defined period, is renewed on use, and can be revoked from a list of active sessions. Done that way, convenience and safety coexist.
What should users be able to see and do?
A list of their active sessions with device and last activity, a button to sign out of all of them, and an automatic sign-out everywhere when they change their password. Those three features let a user recover from a stolen session themselves and are a mark of an application built by people who thought about it.
Sources
- OWASP Cheat Sheet Series: Session Management Cheat Sheet (accessed 2026-09-12)