Secure, HttpOnly, SameSite: the cookie flags that matter

Three small flags decide whether your session cookie is a locked token or a liability: Secure, HttpOnly, and SameSite. Miss them and the cookie that keeps a user logged in becomes the easiest thing on your site to steal or misuse — and nothing looks wrong until it's abused.

These aren't obscure. They're defaults a framework or app builder often doesn't set, and each one closes a specific, well-known attack.

Secure — never send it over plain HTTP

The Secure flag tells the browser to only ever send the cookie over HTTPS. Without it, a single request over http:// — a stray link, a downgrade — sends the session cookie in the clear, where anyone on the network can read it. With it, the cookie simply isn't sent on an insecure connection.

HttpOnly — hide it from JavaScript

HttpOnly makes the cookie invisible to client-side scripts. This is what limits the damage of a cross-site scripting bug: if an attacker manages to run JavaScript on your page, an HttpOnly session cookie is still out of their reach. Leave it off and any injected script can read the cookie and hand the session to someone else.

SameSite — control cross-site sending

SameSite controls whether the cookie is sent on requests coming from other sites. Set to Lax or Strict, it stops another site from silently making authenticated requests as your logged-in user — the mechanism behind CSRF. Lax is a sensible default for most session cookies; Strict is tighter but can log users out when they arrive from an external link.

Check what your cookies are flagged with

You don't have to dig through response headers by hand — a scan shows which flags each cookie carries and which are missing:

Cookie flags are one line on the broader launch security checklist, and they sit alongside the security headers as the outside-view defaults almost every new site is missing.