For a session cookie, use Secure, HttpOnly and SameSite=Strict or Lax, plus the __Host- prefix if you can. Secure keeps the cookie off plain HTTP, HttpOnly hides it from JavaScript, and SameSite limits when browsers send it on cross-site requests.
Secure
A Secure cookie is only sent over HTTPS. MDN notes it is never sent with unsecured HTTP, except on localhost where supported. It does not stop someone with access to the client machine from reading it.
HttpOnly
An HttpOnly cookie cannot be read by JavaScript through document.cookie. It is only visible when it reaches the server. This reduces the damage of cross-site scripting against session cookies, because injected script cannot simply copy the value.
SameSite
SameSite controls whether the cookie travels on cross-site requests.
- Strict: Same-site requests only
- Lax: Same-site requests and top-level navigations such as clicking a link
- None: All requests, including cross-site embeds, and requires Secure
MDN says that if SameSite is omitted, the cookie is treated as Lax.
A safe session cookie
Set-Cookie: __Host-sid=a3fWa; Path=/; Secure; HttpOnly; SameSite=Strict; Max-Age=3600
The __Host- prefix makes browsers require Secure, no Domain attribute and Path=/. That stops sibling subdomains from overwriting the cookie. The server should also check the full cookie name, prefix included.
Other session rules from OWASP
OWASP's session cheat sheet adds points that cookie flags cannot cover:
- Generate IDs with a secure random generator and enough entropy.
- Issue a new session ID after login or any privilege change, and destroy the old one.
- Set idle and absolute timeouts, and enforce them on the server.
- On logout, invalidate the session on the server. Deleting the cookie alone does not invalidate a stolen copy.
- Do not keep session IDs or tokens in localStorage or sessionStorage, because any XSS can read them.
What flags do not do
SameSite helps against cross-site request forgery but OWASP treats it as defense in depth, not a replacement for CSRF tokens. HttpOnly does not stop XSS. It only limits one thing an attacker can steal. Pair cookies with input handling and a content security policy. See a CSP primer.
How to check your own cookies
Open your browser's developer tools, go to the storage or application tab and look at each cookie your site sets.
- Find the session cookie. Confirm Secure and HttpOnly are ticked, and note the SameSite value.
- Check the lifetime. A session cookie that lasts months is a long exposure window.
- Look at the Domain column. A value that starts with a dot means sibling subdomains can see it.
- Log out and confirm the session no longer works on the server by replaying an old request.
Do the same for staging, since staging sometimes uses different settings and then leaks into production by copy.
Quick check
Should every cookie be HttpOnly?
Session and auth cookies should be. A preference cookie that your own JavaScript must read can omit it.
When do I need SameSite=None?
Only for cookies that must travel in cross-site embeds, and it requires Secure. Browsers increasingly block third-party cookies, so plan for failure.
Sources
Last reviewed: 19 October 2026.
