When someone logs in to your site, the server hands their browser a session cookie. From that moment, the cookie is the login: anyone who obtains it is that user, no password needed. Three flags on the cookie decide how hard that theft is.

Secure

A cookie with the Secure flag is only ever sent over HTTPS. Without it, one request over plain HTTP, even an accidental one for an image, broadcasts the session cookie in cleartext for any network eavesdropper to copy. There is no reason for any cookie on a modern site to lack this flag.

HttpOnly

HttpOnly hides the cookie from JavaScript. If an attacker manages to inject script into your page (cross-site scripting), the very first thing that script tries is document.cookie. With HttpOnly set, the session cookie simply is not there to read. The attack that would have been a full account takeover becomes much less valuable.

SameSite

SameSite controls whether the cookie travels along when another site triggers a request to yours. That is the mechanism behind cross-site request forgery: a hostile page silently submits a form to your site, and the browser helpfully attaches the visitor's session cookie.

  • Lax is the sensible default: cookies ride along on normal link clicks but not on cross-site form posts or background requests.
  • Strict never sends the cookie cross-site. Most secure, occasionally annoying (arriving from an email link, you look logged out).
  • None allows everything and requires Secure. Only for cookies that genuinely must work inside third-party contexts.

Check your own cookies

Open your site's response headers and look at Set-Cookie:

curl -sI https://yourdomain.com | grep -i set-cookie

Each cookie should carry Secure; HttpOnly; SameSite=Lax (or stricter) unless there is a documented reason otherwise. A free AuditMerlin scan reads the cookies your homepage sets and flags missing flags, mapped to the OWASP session management guidance.