Cookie flags: Secure, HttpOnly and SameSite in plain words
Three flags protect a visitor’s session from theft and forged requests. What each does, which values to set and how to verify they are on.
Checked against sources: 11 October 2026

- 3flags protect a session cookie
- Laxa sensible SameSite value for most sites
- HTTPSis required for the Secure flag to work
The three flags
- Secure: the cookie travels only over HTTPS, never an open connection.
- HttpOnly: page scripts cannot read the cookie, so injected code cannot steal the session.
- SameSite=Lax (or Strict): the cookie is not sent with hidden requests from other sites, which protects against cross-site request forgery (CSRF).
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Choosing values
Give session cookies all three flags. A cookie your own script must read (say a language choice) can skip HttpOnly but keep Secure and SameSite. SameSite=None is only for embedded services on another domain and must come with Secure.
How to check
Open developer tools, the Application tab, Cookies: each cookie shows Secure, HttpOnly and SameSite marks. Awe Check reads the response headers and names the cookies missing flags.
Frequently asked
Do I need Secure if the whole site is on HTTPS?
Yes. The flag guarantees the cookie never leaves over http if a visitor opens an old unprotected link.
Does the law require it?
Not directly, but session protection is part of the technical measures data protection laws expect. Without the flags it is hard to prove you took reasonable steps.
What is the SameSite default?
Chrome and Edge treat a cookie without the attribute as SameSite=Lax while other browsers behave differently. State the value explicitly so behaviour does not depend on the browser.
