What we check/Security headersHD-07

Cookie flags

Cookies should be Secure, HttpOnly, and carry a SameSite value.

Area

Security headers

Check

HD-07

Included

Free in every scan

What we check

We read the Set-Cookie headers on your homepage and check the flags on each.

A site that sets no cookies passes — there is nothing to protect.

Why it matters

Secure keeps the cookie off plain-HTTP requests. HttpOnly keeps it away from JavaScript, so an injected script cannot read a session. SameSite stops it being attached to requests originating from other sites.

Between them they turn a stolen session from likely into difficult.

The flags matter most in combination. HttpOnly alone still lets a cookie travel over plain HTTP; Secure alone still lets an injected script read it. Each closes a different route to the same session.

How to fix it

1. 1

   Set all three on every cookie that matters, especially the session cookie.

2. 2

   Start with the session cookie; it is the one whose theft matters most.

3. 3

   Start with the session cookie; it is the one whose theft matters most.

4. 4

   Check cookies set by third-party scripts too — a readable cookie on your domain is your exposure whoever wrote the code that set it.

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/

Common questions

What is the difference between Lax and Strict?

Lax sends the cookie on top-level navigation from another site, so following a link into your app keeps you logged in. Strict does not, which is safer and more surprising to users.

Can I use SameSite=None?

Only with Secure, and only when you genuinely need cross-site requests. Browsers reject None without Secure.

What about cookies my analytics tool sets?

They should have the flags too. A third-party script setting a readable cookie on your domain is still your exposure.