The Danger of Insecure Cookies
HTTP is a stateless protocol. To remember who a user is (e.g., that they are logged in), websites use cookies. These small pieces of data are stored in the browser and sent with every request.
Because cookies often contain sensitive session IDs, they are a gold mine for attackers. If an attacker can steal a user's session cookie, they can impersonate that user—a technique known as Session Hijacking.
Common Attack Vectors
- XSS (Cross-Site Scripting): Injecting malicious JavaScript to read `document.cookie`.
- Man-in-the-Middle (MITM): Intercepting cookies sent over plain HTTP.
- CSRF (Cross-Site Request Forgery): Tricking the browser into sending cookies to a malicious site.
HttpOnly: Stopping XSS
The HttpOnly flag is one of the most effective defenses against XSS-based cookie theft. When a cookie is flagged as HttpOnly, the browser refuses to reveal it to client-side scripts.
How it works
If a hacker injects a script like alert(document.cookie) on your page, an HttpOnly cookie will not appear in the alert. The browser still sends the cookie to the server with every request, but JavaScript cannot touch it.
Set-Cookie: session_id=xyz123; HttpOnlySecure: Encryption Only
The Secure flag tells the browser: "Only send this cookie if the request is being made over HTTPS."
Without this flag, if a user accidentally types http://yourbank.com instead of https://, the browser might send the session cookie over plain text, allowing an attacker on the same network to intercept it.
Set-Cookie: session_id=xyz123; SecureNote: You must have an SSL certificate installed to use this flag effectively.
SameSite: Preventing CSRF
The SameSite attribute controls when cookies are sent with cross-site requests. It effectively neutralizes most CSRF attacks.
Values:
- Strict: The cookie is only sent if the request originates from your own site. It will NOT be sent if a user clicks a link to your site from an email or another website. Use this for highly sensitive actions.
- Lax: The cookie is not sent on cross-site subrequests (like images or frames) but IS sent when a user navigates to your site (top-level navigation). This is the modern default and balances security with UX.
- None: The cookie is sent with all requests, cross-site or not. Requires the
Secureflag.
Set-Cookie: session_id=xyz123; SameSite=LaxBest Practices Checklist
Review your application's cookie settings against this checklist:
- ✅ HttpOnly: Enabled for all session identifiers.
- ✅ Secure: Enabled for all cookies in production (HTTPS).
- ✅ SameSite: Set to 'Lax' or 'Strict' depending on your needs.
- ✅ Domain & Path: Scoped as narrowly as possible.
- ✅ Expiration: Set reasonable expiration times; don't make session cookies last forever.
Frequently Asked Questions
What happens if I don't use the HttpOnly flag?
Without HttpOnly, any JavaScript on your page can access the cookie. If an attacker finds an XSS vulnerability, they can steal the session cookie and hijack the user's account.
Does SameSite=Strict break functionality?
It can. 'Strict' prevents the cookie from being sent on any cross-site request, including top-level navigations (clicking a link to your site). 'Lax' is the recommended default for most sites as it balances security and usability.
Can I use Secure cookies on localhost?
Generally no, because localhost is HTTP by default. However, modern browsers treat localhost as a secure context, so some development environments may allow it. For production, HTTPS is mandatory for Secure cookies.
How do I set these flags?
You set them in the 'Set-Cookie' HTTP response header from your server. Most web frameworks (Express, Django, Rails, etc.) have simple configuration options to enable them.
Check Your Cookie Security
Our comprehensive scan checks if your site is using HttpOnly, Secure, and SameSite flags correctly.
Run Free Security Scan