Cookie Security & Session Hardening: SameSite, HttpOnly, Secure
Cookie security attributes significantly reduce attack surface for session hijacking, XSS, and CSRF. HttpOnly prevents JavaScript access, Secure ensures HTTPS-only transmission, and SameSite controls cross-site behavior. These must be combined with proper session lifecycle management.
HttpOnly = sealed envelope (JS can't read inside). Secure = only delivered by trusted courier (HTTPS). SameSite = only delivered when the recipient is from the same organization (same-site context).
HttpOnly
JS cannot read
Secure
Only over HTTPS
SameSite
Controls cross-site sending
1HttpOnly
Prevents JavaScript from accessing the cookie via document.cookie. Critical for session identifiers to reduce XSS impact.
2Secure
Ensures the cookie is only sent over HTTPS connections. Essential in production to prevent interception on unsecured networks.
3SameSite Attribute
Controls whether cookies are sent in cross-site requests. Strict offers strongest CSRF protection; Lax balances usability; None requires Secure.
| Property | HttpOnly | Secure | SameSite |
|---|---|---|---|
| Limitation | Does not stop XSS execution itself | Does not prevent JS access | Some flows may need None (with Secure) |
| Protects Against | XSS cookie theft | Network interception (MITM) | CSRF via cross-site requests |
HttpOnly
Limitation
Does not stop XSS execution itself
Protects Against
XSS cookie theft
Secure
Limitation
Does not prevent JS access
Protects Against
Network interception (MITM)
SameSite
Limitation
Some flows may need None (with Secure)
Protects Against
CSRF via cross-site requests
Common questions
- ›“What do HttpOnly, Secure, and SameSite do?”
- ›“How do you harden session cookies?”
- ›“Explain SameSite=Strict vs Lax vs None.”
- ›“Why combine multiple cookie attributes?”
What interviewers look for
- Clear understanding of each attribute's purpose
- Knowledge of trade-offs and when to use each
- Awareness of cookie prefixes and scope control
- Holistic session hardening (lifecycle + attributes)
Short answer (60 sec)
HttpOnly prevents JavaScript access, Secure restricts to HTTPS, SameSite controls cross-site sending. Combine them for strong session protection. Use __Host- prefix for critical cookies.
Detailed answer (senior level)
Cookie security is multi-layered. HttpOnly stops XSS-based theft, Secure prevents plaintext transmission, SameSite reduces CSRF risk. Combine with narrow Domain/Path scope, session rotation on login, and proper invalidation on logout. Cookie prefixes like __Host- add extra defense-in-depth.
- Missing HttpOnly on session cookies
- Using Secure=false in production
- Not setting SameSite explicitly
- Overly broad Domain or Path scope
- Forgetting to rotate session IDs after login
- ✓HttpOnly prevents JS access to sensitive cookies
- ✓Secure ensures transmission only over HTTPS
- ✓SameSite controls cross-site cookie behavior
- ✓Use __Host- and __Secure- prefixes for extra protection
- ✓Narrow cookie scope with Domain and Path
- ✓Combine with proper session lifecycle management
- ✓Cookie hardening is defense-in-depth, not a complete solution
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.