5 min read
Session security — revocation, idle timeout, rotation
A logged-in user is a trust decision you made at login. Sessions need explicit policies for idle timeout, absolute timeout, revocation, and rotation.
Most session bugs are about what happens AFTER login — how long the session lives, what invalidates it, and who can revoke it.
What it is
A session is the server-side record of an authenticated user. It has a lifetime, an expiration policy, and a revocation interface.
Vulnerable example
// Vulnerable: session lives forever, no revocation list
// Login issues a JWT with no expiration.
// User changes password; old JWT still valid.
// Team member leaves; their tokens are still valid.Fixed example
// Fixed: short-lived tokens + revocation list + rotation
// 1. Access tokens expire in 15 minutes.
// 2. Refresh tokens last 30 days but rotate on each use with reuse detection.
// 3. Password change revokes all sessions for the user.
// 4. Admin UI to revoke any active session.
// 5. Session table indexed on user_id and last_seen_at for cleanup.How Securie catches it
Securie's session specialist flags auth systems that issue long-lived tokens without revocation or rotation.
Checklist
- Access tokens expire in minutes, not days
- Refresh tokens rotate with reuse detection
- Password change revokes all sessions for the user
- Admin interface exists to revoke any session
- Idle timeout (30 min for sensitive actions, 7 days for general)
- Session table cleaned up (no unbounded growth)
FAQ
JWT or server-side session?
For most web apps, server-side sessions with a short cookie are simpler and safer. JWTs are useful for cross-service auth and public APIs but require careful revocation design.