Renew the session ID at sign in and at any change of privilege level, such as a password change or switching to an admin role. Require re-authentication after risky events. End the session on logout, and on idle and absolute timeouts enforced on the server. OWASP's session cheat sheet describes each.
Three different actions
People often mix up three responses. They are not the same.
| Action | What it does | Use when |
|---|---|---|
| Renew | Issue a new session ID, destroy the old one, keep the user signed in | Privilege changes, periodic hardening |
| Re-authenticate | Ask the user to prove identity again, then continue | A risky action or event |
| End | Invalidate the session so the user must sign in again | Logout, timeouts, account changes |
Events that should renew the session ID
The OWASP Session Management Cheat Sheet says the session ID must be renewed after any privilege level change. The most common case is sign in, when the user moves from anonymous to authenticated. Other cases it names are password changes, permission changes, and switching from a regular user role to an administrator role.
The main reason is session fixation, where an attacker sets a known session ID in the victim's browser and waits. If you issue a new ID at sign in, the attacker's value is useless. OWASP also suggests using a different session cookie name before and after authentication, so anonymous and authenticated state do not mix.
Events that should require re-authentication
OWASP says web applications should require re-authentication after high risk events, including changes to critical user information such as password or email address, sign in attempts from new or suspicious IP addresses or devices, and account recovery flows.
Practical triggers to add:
- Changing email, phone or MFA settings.
- Adding a new passkey or API key.
- Starting a payment or data export.
- A session resumed after a long idle period.
Events that should end the session
- Logout. OWASP says a visible logout control must be reachable from every page, and the session must be invalidated at least on the server.
- Idle timeout. All sessions should have one, enforced on the server.
- Absolute timeout. All sessions should have a maximum life regardless of activity, which limits how long a hijacked session helps an attacker.
- Password reset or account lock. End other sessions, since the reason for the reset may be a compromise.
- Detected theft. End the session and notify the user.
OWASP stresses that timeouts must be enforced on the server. If the client tracks the time, an attacker can manipulate it.
Optional: renewal timeout
Beyond idle and absolute limits, OWASP describes a renewal timeout: after some time, the app issues a fresh session ID mid session, keeps the old one valid briefly, then invalidates it. It reduces how long a stolen ID is useful, even while the user remains active.
Concurrent sessions
Whether to allow simultaneous sign ins is a design choice. OWASP recommends letting users view active sessions, get alerts about concurrent sign ins, and end sessions remotely, along with an activity log of IP address, user agent and times.
Cleaning up on the client
After logout, private data may still sit in the browser cache. OWASP advises Cache-Control: no-store on responses with session data, and suggests the Clear-Site-Data header at logout to remove cached resources, cookies and storage for the origin. It also warns that browser close events cannot reliably enforce logout, so never depend on them.
A one page rule set
Write down, for your app, a table of events and the action each triggers. Review it when you add a feature that changes privilege. It takes an hour and catches the quiet gaps.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the findings a live scan reports on a running app, such as cookie and session handling, and compare them with the table above.
Quick check
Should a password change end all other sessions?
OWASP lists password changes as a privilege level change that needs a new session ID. Ending other sessions is a common and sensible extra step, because the change may follow a compromise.
Can I rely on a short cookie lifetime instead of server timeouts?
No. OWASP says expiry must be enforced on the server. A client controlled value can be altered.
Safeguard's SBOM and dependency scanning shows which session and auth libraries you ship, which helps when a framework advisory affects session handling. A free scan is available.
Sources
Last reviewed: 19 October 2026.
