Cookies and their security flags: Secure, HttpOnly and SameSite
A cookie is a note the browser sends with every request. Three flags decide whether it can be stolen or misused. What each does and which to set.
The short answer
A cookie is a small value a website asks the browser to store and send back with every later request to that site. It is how a site remembers you between pages, and in particular how it remembers that you logged in. That makes session cookies valuable: whoever holds one is, as far as the site knows, you. Three flags on a cookie decide how easily it can be stolen or misused: Secure, HttpOnly and SameSite. For a session cookie, set all three.
Many business websites built as static sites set no cookies at all. That is the simplest state to keep secure and compliant.
The three flags
| Flag | What it does | Without it |
|---|---|---|
| Secure | The browser only sends the cookie over HTTPS | The cookie can travel in plain text over an http request and be read on the network |
| HttpOnly | Scripts on the page cannot read the cookie; only the browser sends it | Any injected or malicious script can read and exfiltrate the session |
| SameSite | Controls whether the browser sends the cookie on requests that start from another site | Another site can make the browser send your session along with a forged request |
SameSite, in plain terms
SameSite answers the question: if a request to your site starts from somewhere else, should the cookie come along?
- Strict: never. The user arrives from an email link logged out, because the cookie was not sent. Safest, and occasionally annoying.
- Lax: not on cross-site form posts or background requests, but yes on a top-level navigation such as following a link. Logins survive normal browsing; forged requests do not carry the session. The sensible default for most session cookies.
- None: always, provided the cookie is also Secure. Only for cookies that genuinely must work across sites, such as embedded widgets that need their own session.
The right settings for a session cookie
- Secure, always. The site is HTTPS-only anyway.
- HttpOnly, so no script can read it, whatever else goes wrong on the page.
- SameSite=Lax, or Strict for sensitive admin sessions.
- A scoped path and domain: no wider than needed, and never shared across unrelated subdomains.
- A sensible expiry: hours for admin sessions, longer only for deliberate “remember me” choices, with the session invalidated on the server at logout.
- A prefix such as __Host- where supported, which forces Secure, no domain attribute and a root path, so the cookie cannot be overridden by a subdomain.
Where this fits with everything else
Cookie flags are one layer. A content security policy limits which scripts can run at all; HSTS ensures every request is HTTPS; input handling prevents the cross-site scripting that would try to read the cookie in the first place. Each layer assumes another might fail. That is the point of setting all of them rather than picking one.
What this means for you
If your site or app keeps people logged in, ask whether the session cookie carries all three flags and a short lifetime. It is a one-line fix with a large effect, and it is one of the first things any security scan checks. If your site is static and sets no cookies, you have the simplest possible answer to both security and consent, and it is worth keeping it that way when someone proposes a new tag or widget.
Frequently asked questions
Do we need a cookie banner if the site sets cookies?
Consent rules apply to cookies that are not strictly necessary, such as analytics and marketing cookies. A session cookie needed to keep a customer logged in does not require consent. What you must never do is show a banner claiming cookies you do not set, or set tracking cookies before consent. Check with a privacy specialist for your jurisdiction.
What happens if the HttpOnly flag is missing?
Any script running on the page can read the cookie. If an attacker manages to inject a script through a cross-site scripting flaw or a compromised third-party tag, they can read the session cookie and use it to act as the logged-in user. HttpOnly closes that path.
Which SameSite value should we use?
Lax for most session cookies: it blocks the cookie on cross-site form posts and background requests but still sends it when a user follows a link to your site, so logins are not broken by normal navigation. Strict for very sensitive actions, accepting that links from email will arrive logged out. None only when a cookie must work across sites, and then it must also be Secure.
Sources
- MDN: Using HTTP cookies (accessed 2026-09-11)
- MDN: Set-Cookie header (accessed 2026-09-11)