Cookie Attributes Explained: Secure, HttpOnly, SameSite
How a handful of cookie flags control exposure to theft, cross-site requests, and script access.
Core Concept
Cookie attributes, set via the Set-Cookie response header, control how a cookie can be accessed and transmitted, directly affecting its exposure to several classes of attack.
Misconfigured cookie attributes are a recurring, high-impact finding in security reviews, since cookies frequently carry sensitive session identifiers.
The Secure Attribute
The Secure attribute restricts a cookie to being sent only over HTTPS connections.
- Prevents the cookie from being transmitted over plain HTTP
- Protects against interception on unencrypted network segments
- Should be set on virtually every cookie on an HTTPS site
No Reason to Omit
On any site fully served over HTTPS, there's essentially no legitimate reason to omit the Secure attribute from cookies.
The HttpOnly Attribute
HttpOnly prevents client-side JavaScript from reading a cookie's value, closing a major avenue for cookie theft via cross-site scripting.
- Cookie inaccessible to document.cookie in JavaScript
- Significantly limits the impact of an XSS vulnerability on session theft
- Should be set on session and authentication cookies specifically
The SameSite Attribute
SameSite controls whether a cookie is sent along with cross-site requests, providing a significant layer of CSRF protection.
It supports three values — Strict, Lax, and None — each offering a different balance between protection and cross-site functionality.
Modern Default: Lax
Many browsers now default cookies to SameSite=Lax if unspecified, meaning cross-site behavior may already be more restricted than developers expect.
Choosing the Right SameSite Value
The appropriate value depends on how the cookie needs to behave across sites.
- Strict — maximum protection, cookie never sent cross-site
- Lax — sent on top-level navigation, blocked on most cross-site requests
- None — sent on all requests, requires Secure attribute as well
Real-World Implementation
Proper cookie attribute configuration is a baseline expectation for any authenticated web application.
- Session cookies universally using Secure, HttpOnly, and an appropriate SameSite value
- Security scanners specifically checking cookie attribute configuration
- Frameworks increasingly defaulting to secure cookie settings out of the box
Correctly configuring these three attributes on every sensitive cookie remains one of the highest-value, lowest-effort security improvements available to most applications.
Common Mistakes to Avoid
A few common mistakes leave cookies more exposed than necessary.
- Omitting the Secure attribute on cookies for a site fully served over HTTPS.
- Leaving session cookies readable by JavaScript without the HttpOnly attribute.
- Setting SameSite=None without also including the required Secure attribute.
- Assuming default browser SameSite behavior matches what the application actually needs.
- Failing to review cookie attribute configuration as part of regular security reviews.
- Overlooking the Domain and Path attributes when scoping a cookie's visibility.
- Assuming SameSite=Lax fully protects against all forms of CSRF.
- Failing to test cookie behavior across different browsers given evolving default policies.
- Overlooking cookie prefixes (__Host- and __Secure-) as an additional layer of enforcement.
- Assuming third-party cookie restrictions don't affect first-party cookie behavior.
- Failing to audit all cookies set by third-party scripts embedded on the site.
- Overlooking that some browser privacy modes apply stricter default cookie handling automatically.
Best Practices Checklist
These practices help ensure cookies are configured securely by default.
- Set Secure, HttpOnly, and an appropriate SameSite value on every sensitive cookie.
- Verify SameSite=None is always paired with the Secure attribute as browsers require.
- Review cookie attribute configuration as a standard part of security audits.
- Understand current default SameSite behavior rather than assuming it matches expectations.
- Apply HttpOnly specifically to session and authentication cookies without exception.
- Scope cookies deliberately using Domain and Path attributes rather than leaving them overly broad.
- Combine SameSite with other CSRF protections rather than relying on it exclusively.
- Test cookie behavior across multiple browsers given ongoing changes to default SameSite handling.
- Use cookie prefixes like __Host- and __Secure- for additional browser-enforced guarantees.
- Understand that evolving third-party cookie restrictions are distinct from first-party cookie handling.
- Audit cookies set by embedded third-party scripts, not just those set by your own code.
- Test cookie behavior specifically under stricter browser privacy modes, not just default settings.
Frequently Asked Questions
Frequently asked questions about cookie security attributes.
What does the Secure attribute do?
It restricts a cookie to being sent only over HTTPS connections, protecting it from interception on unencrypted network segments.
Why is HttpOnly important for session cookies?
It prevents client-side JavaScript from reading a cookie's value, significantly limiting the impact of an XSS vulnerability on session theft.
What are the three SameSite values and what do they do?
Strict never sends the cookie cross-site, Lax sends it on top-level navigation while blocking most cross-site requests, and None sends it on all requests.
Does SameSite=None have any special requirements?
Yes — browsers require it to be paired with the Secure attribute, rejecting the combination of None without Secure entirely.
Is there ever a reason to omit Secure on an HTTPS site?
Essentially no — on any site fully served over HTTPS, there's no legitimate reason to omit the Secure attribute from cookies.
What do the Domain and Path cookie attributes control?
They scope exactly which domains and URL paths a cookie is sent to, an important but often overlooked part of cookie configuration.
Does SameSite=Lax fully prevent CSRF attacks?
It significantly reduces risk but isn't a complete standalone defense — combining it with other CSRF protections is still recommended.
Why does cookie behavior need testing across different browsers?
Because default SameSite handling has evolved and can differ slightly between browsers, making cross-browser testing worthwhile.
What do cookie prefixes like __Host- actually enforce?
The __Host- prefix enforces stricter browser-level requirements, like requiring Secure and disallowing a Domain attribute, adding tamper resistance.
Are third-party cookies handled the same as first-party ones?
No — browsers increasingly apply distinct, more restrictive policies to third-party cookies, separate from standard first-party cookie behavior.
Do browser privacy modes change default cookie handling?
Yes — many apply stricter default restrictions in private or incognito modes, worth testing separately from standard browsing behavior.
Check Cookie Security Attributes
Run an HTTP header analysis to see how a domain's cookies are configured.
Launch Tool →