TL;DR
Session security prevents attackers from hijacking user sessions. Key measures include secure cookie settings, session ID regeneration, proper timeouts, and server-side session storage. These prompts help you implement defense-in-depth for your sessions.
Secure Cookie Configuration
Configure my session cookies with proper security settings.
Framework: Next.js/Express/Django/Rails
Required cookie attributes:
- HttpOnly: true (prevents JavaScript access)
- Secure: true (HTTPS only)
- SameSite: 'Strict' or 'Lax'
- Path: '/' (or specific paths)
- Domain: only if needed for subdomains
Set appropriate expiration:
- Session cookie: no Max-Age (browser session)
- Persistent: Max-Age based on security needs
Show how to set these in my framework's session config. Also show how to verify settings in browser DevTools.
Session ID Management
Implement proper session ID management to prevent fixation attacks.
Requirements:
- Generate cryptographically random session IDs
- Regenerate session ID on authentication
- Regenerate on privilege escalation
- Invalidate old session ID completely
- Use sufficient entropy (128+ bits)
Implement regeneration on:
- Successful login
- Password change
- Permission level change
- Switching from HTTP to HTTPS
Show implementation for my session library. Include migration of session data to new ID.
Always regenerate session ID on login: Session fixation attacks trick users into using a known session ID. Regenerating after login makes any pre-set session ID useless.
Session Timeout Configuration
Add proper session timeout handling.
Implement two types of timeout:
- Absolute timeout: 24 hours max session life
- Idle timeout: 30 minutes of inactivity
For sensitive operations:
- Re-authenticate for password changes
- Re-authenticate for payment actions
- Short-lived elevated sessions (15 min)
Implementation needs:
- Server-side timeout tracking
- Sliding window for idle timeout
- Grace period warning to user
- Clean session termination
- Audit log of timeout events
Don't rely only on cookie expiration - validate server-side.
Server-Side Session Storage
Move from client-side to server-side session storage.
Current: Session data in JWT/cookie Target: Server-side with Redis/database
Benefits of server-side:
- Can invalidate sessions immediately
- No size limits from cookie
- Sensitive data not exposed to client
- Can track active sessions per user
Implement:
- Redis session store setup
- Session cleanup job for expired sessions
- List active sessions for user
- Revoke specific sessions
- Revoke all sessions (logout everywhere)
Store only session ID in cookie. Store session data in Redis with TTL matching timeout.
Pro tip: Bind sessions to additional factors like IP address or user agent fingerprint. Flag sessions for review if these change mid-session.
Should I use sessions or JWTs?
Sessions are better for traditional web apps because you can revoke them instantly. JWTs work better for stateless APIs and mobile apps where server-side storage is impractical.
How long should sessions last?
Depends on your security requirements. Banking apps might use 15-minute idle timeouts. Social apps might allow days. Always have an absolute maximum regardless of activity.