What do secure cookie flags protect?
Secure restricts a cookie to HTTPS connections. HttpOnly prevents JavaScript from reading the cookie through document.cookie. SameSite controls whether browsers attach the cookie to cross-site requests and provides an important layer against CSRF.
These attributes solve different problems and should usually be combined for authentication cookies. A Secure cookie is not automatically HttpOnly, and SameSite does not encrypt or hide its value.
Which SameSite value should I use?
SameSite=Lax is a practical baseline for many sessions because it blocks most cross-site subrequests while allowing common top-level navigation. Strict provides tighter isolation but can disrupt legitimate flows arriving from external sites.
SameSite=None is intended for genuinely cross-site use and must be paired with Secure. Review embedded apps, identity providers, payment flows, and multi-domain products before changing production cookies.
What are the limits of an external cookie scan?
A passive external scan sees cookies returned to the unauthenticated request it makes. Cookies created only after login, consent, geographic routing, or client-side interactions may not appear in that response.
Use the external result as a fast baseline, then inspect authenticated browser sessions and every response that creates or rotates sensitive cookies. Never store credentials or unnecessary personal information directly in readable cookie values.
Frequently asked questions
Should every cookie be HttpOnly?
Cookies needed by client-side JavaScript cannot be HttpOnly, but session and authentication cookies generally should be.
Does Secure encrypt a cookie?
No. It requires HTTPS transport. TLS encrypts the connection carrying the cookie.
Why did the scan find fewer cookies than my browser?
Some cookies appear only after consent, login, scripts, redirects, or region-specific responses.