Introduction
Secure session configuration prevents session hijacking and other attacks.
Key Concepts
Session Hijacking: Stealing session cookies.
Session Fixation: Attacker sets victim's session ID.
Real World Context
A banking application must protect session cookies from theft. If an attacker injects JavaScript via XSS, SESSION_COOKIE_HTTPONLY = True prevents the script from reading document.cookie. Combined with SECURE and SAMESITE, this layered defense makes session hijacking significantly harder.
Deep Dive
Production Settings
python# settings.py SESSION_COOKIE_SECURE = True # HTTPS only SESSION_COOKIE_HTTPONLY = True # No JavaScript access SESSION_COOKIE_SAMESITE = 'Lax' # CSRF protection # Rotate session on login (built-in) # django.contrib.auth.login() does this automatically
Session Fixation Prevention
pythonfrom django.contrib.auth import login def login_view(request): # login() automatically rotates session key login(request, user) # Old session ID is now invalid
Logout Security
pythonfrom django.contrib.auth import logout def logout_view(request): logout(request) # Flushes session completely return redirect('home')
Common Pitfalls
- Forgetting
SESSION_COOKIE_SECUREin production: Without it, cookies are sent over plain HTTP. An attacker on the same network (e.g., public Wi-Fi) can intercept them with a packet sniffer. - Setting
SESSION_COOKIE_SAMESITE = 'None'withoutSecure: Browsers rejectSameSite=Nonecookies that are not also markedSecure. This silently breaks sessions. - Not calling
logout()on session expiry: WhenSESSION_EXPIRE_AT_BROWSER_CLOSE = True, the cookie is deleted when the browser closes, but the server-side session data remains. Runclearsessionsperiodically to clean up.
Best Practices
- Always use HTTPS: In production.
- Set SameSite: 'Lax' or 'Strict'.
- Short session lifetime: For sensitive apps.
Summary
Enable all cookie security flags in production. Django handles session rotation on login automatically.