July 15, 2026 · 2 min read
Secure, HttpOnly, SameSite: What Your Cookies Should Look Like
Cookies are how most websites remember that you're logged in between page loads. That makes them a high-value target — and three small flags on each cookie decide how much protection it actually gets.
Secure — Only Sent Over HTTPS
Without the Secure flag, a browser will happily send a cookie over plain, unencrypted HTTP too. On a shared network — public WiFi, for instance — that means the cookie can potentially be intercepted in transit and reused by someone else.
HttpOnly — Invisible to JavaScript
A cookie with HttpOnly can't be read by any client-side JavaScript, including malicious scripts injected through an XSS vulnerability. Without it, a successful XSS attack can simply read the session cookie directly and hijack the account — HttpOnly closes that specific path.
SameSite — Limiting Cross-Site Requests
SameSite controls whether a cookie is sent along with requests originating from a different site. Set to Strict or Lax, it significantly reduces the risk of CSRF (Cross-Site Request Forgery), where a malicious page tricks a logged-in user's browser into making an unwanted authenticated request.
Why All Three Together Matter
Each flag closes a different attack path — network interception, script injection, and cross-site trickery. A session cookie missing even one of the three leaves a real gap, and in most frameworks setting all three correctly is a single configuration change, not a development project.
Common cookie mistakes
Setting the Secure flag but forgetting HttpOnly, or vice versa — they protect against different things (Secure stops transmission over plain HTTP; HttpOnly stops JavaScript access) and a cookie needs both to meaningfully resist both network interception and XSS-based theft.
Using `SameSite=None` without also setting `Secure`, which modern browsers reject outright — the cookie silently fails to be set at all, which can look like a confusing, hard-to-diagnose login or session bug rather than an obvious cookie-flag error.
Check Your Cookies
Nexora Shield's Cookie Security Scanner checks any website's cookies for these three flags and reports exactly which ones are missing.
Frequently Asked Questions
Which cookie flag matters most if I can only fix one?
HttpOnly is usually the highest priority for session cookies, since it directly blocks the most common real-world attack path — an XSS vulnerability reading the cookie via JavaScript.
Does SameSite=Strict ever break normal site functionality?
Yes, it can block cookies from being sent when a user arrives via an external link (like from an email or another site), which is why SameSite=Lax is the more common default for balancing security and usability.
Cookie Security Scanner
Checks any website's cookies for Secure, HttpOnly, and SameSite flags.
Related Articles
What Is a Content Security Policy (CSP) and Why You Need One
Understand what CSP headers do, how they prevent XSS attacks, and how to write your first policy.
Headers & PoliciesCORS Misconfigurations: What They Are and How Attackers Exploit Them
Understand what Cross-Origin Resource Sharing actually controls, the most dangerous misconfiguration pattern, and how to test for it.
PrivacyWas My Email Hacked? How to Check for Data Breaches (2026)
Find out if your email address was exposed in a data breach, what attackers actually do with it, and the exact steps to lock your accounts down today.