Is your sign-in cookie missing a protection?
This check recognises the session cookie of a known sign-in library on responses a Deep scan reads, and flags one set without Secure, HttpOnly or SameSite, or shared with every subdomain.
What does this check look at?
It looks at whether the session cookie of a known sign-in library is set without Secure, HttpOnly or SameSite, or is shared with every subdomain. MDN describes HttpOnly as forbidding JavaScript from accessing the cookie and notes that setting the domain makes the cookie available to that domain and all its subdomains.
Only a Deep scan runs it, after you prove you own the site.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Low or medium finding | A recognised session cookie lacks a protective attribute. | Set the attribute in your auth library config. |
Nobody signs in and the cookie is never used, so it does not show a session can be stolen. 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 high, because a response from your site shows the thing itself. 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 | Someone on the visitor's network, or script on the page |
| The protection that should stop it | A protective attribute is missing on a recognized session cookie |
| What is reached | A signed-in visitor's session cookie |
| What follows | A hardening gap; no session was used or taken |
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 it once in the sign-in library settings, so every route issues the cookie the same way.
My sign-in library issues its session cookie without some protections: [paste the missing attributes from the report]. In my auth library configuration (not per route), set the session cookie to Secure, HttpOnly and SameSite=Lax (None only if a cross-site flow truly needs it), and remove the Domain attribute unless my subdomains must share the session. Prefer the __Host- prefix if the library supports it. Add a test that checks the Set-Cookie attributes.How to check
Say Atlas, our example app at atlas.example, set its session cookie domain to the whole domain so a help subdomain could share it. A Deep scan flags the wide scope.
Deep scans come with the Deep plan, and pricing shows what it includes. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
How does the scan know which cookie is the session?
From the cookie names that common sign-in libraries document. The value is never kept or used.
Is this different from the cookie flags check?
Yes. That one reads any cookie on public pages. This one only looks at recognised session cookies, which matter most.
Run this check on your site
Only a Deep scan runs this check, once you prove you own the site. Deep walks your whole site, the scripts it loads and your API surface.
Run a Deep scanSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Set-Cookie header MDN Web Docs, read on October 7, 2026