Do the cookies on your public pages carry the right protections?
The cookie flags check reads the Secure, HttpOnly and SameSite settings on cookies your public pages set. Cookie flags keep sign-in cookies out of reach of scripts and away from unencrypted connections.
What does this check look at?
It looks at whether cookies set on public pages ask for HTTPS only, stay out of reach of scripts and declare how they behave across sites. MDN describes HttpOnly as forbidding JavaScript from accessing the cookie, and SameSite as some protection against cross-site request forgery.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | Cookies seen on public pages carry the expected flags. | Nothing. |
| Attention | A cookie lacks Secure, HttpOnly or a deliberate SameSite. | Decide what the cookie is for, then set the right flags. |
| Not tested | No cookies were set, or the page builds itself in the browser. | Nothing to act on. |
The scan does not know what each cookie is for, and some cookies need to be readable by scripts on purpose. Cookie names and values are not kept. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Scripts or networks that can see cookies |
| The protection that should stop it | Cookie protection flags are missing |
| What is reached | Cookie values |
| What follows | A hardening gap; no session was read |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A07:2025 Authentication Failures |
| CWE | CWE-614 |
| CWE | CWE-1004 |
| CWE | CWE-1275 |
| ASVS | v5.0.0-3.3.1 |
| ASVS | v5.0.0-3.3.2 |
| ASVS | v5.0.0-3.3.4 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
Change flags on purpose, cookie by cookie, because a consent banner or analytics cookie may need to stay readable.
List every cookie my site sets and what each one is for. For any cookie that holds a session, login or CSRF token, make sure it is set with Secure, HttpOnly and SameSite=Lax (or Strict if cross-site links do not need it). Set Secure on every other cookie too. Leave a cookie readable by JavaScript only if my code really reads it, and tell me which ones those are. Make the change in my auth library or framework config, not route by route.How to check
Say Atlas, our example app at atlas.example, sets a preferences cookie without Secure on its homepage. The check flags it, and the fix is one attribute.
The free quick check covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. Pulse or Deep explains the difference.
Questions people ask
Should every cookie be HttpOnly?
No. Some cookies are meant to be read by your own scripts, such as a theme or consent choice. Session and login cookies should be HttpOnly.
What about my sign-in cookie, which only appears after login?
Pulse never signs in. A Deep scan recognises the session cookies of common sign-in libraries when they are set on public responses, and that has its own check.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Security settings your site sends to browsers Lockpick docs, read on October 7, 2026
- Set-Cookie header MDN Web Docs, read on October 7, 2026