HTTP security
Cookie security checker
See the cookies a site's home page sets over HTTPS and whether each carries the attributes that keep it off plain HTTP, out of reach of scripts and out of requests that start on other sites.
What this checks
- Every
Set-Cookieheader on the HTTPS responses for the home page, redirects included, for the domain and itswww.name, or the subdomain entered. Up to 10 cookie names per host are judged. Secureon every cookie. Without it, the finding is medium severity when the name looks like a session or sign-in cookie, and low otherwise.HttpOnlyon cookies whose names suggest a session or sign-in token, such as names containingsess,sid,auth,tokenorjwt. Other cookies may legitimately be read by scripts and are not judged on it.SameSiteon every cookie, with its value shown.- Each cookie's name and attributes are listed. Values are removed by the scanner before anything is kept or shown.
What the result means
A cookie's attributes decide where the browser sends it and who can read it. Secure keeps it to HTTPS connections. HttpOnly hides it from JavaScript, so a script injected into the page cannot read it. SameSite controls whether it travels with requests that start on another site: Strict never, Lax only when the visitor follows a link to the site, None always, and then it must also be Secure.
Session and sign-in cookies matter most, because whoever holds one is, to the site, the signed-in user. The check recognises them by name, so a session cookie with an unusual name is judged like any other cookie, and a harmless one with token in its name may be flagged.
A pass means the home page set no cookies, or every cookie had Secure and SameSite and every session-like cookie had HttpOnly. Many sites set no cookies on the home page at all; that is a genuine pass, not a sign the check did not look.
How to fix common issues
Cookie set without the Secure flag
Add the Secure attribute to every cookie the site sets over HTTPS.
Session cookie readable by scripts
Add the HttpOnly attribute to session and authentication cookies.
Cookie set without SameSite
Add SameSite=Lax (or Strict where possible) to cookies.
Scope and limitations
- It sees only cookies the public home page sets. Session cookies are usually set after signing in, on other paths or by an application on another host, and none of those are visited.
- Cookies set by JavaScript in the browser, including by third-party scripts, are not seen. The check does not run scripts.
- Recognising a session cookie by its name is a guess. Review any finding against what the cookie actually does.
Related guides
Questions
- What is the difference between Secure and HttpOnly?
- Secure stops the browser sending the cookie over plain HTTP. HttpOnly stops JavaScript on the page reading it. A session cookie should have both.
- Which SameSite value should I use?
- Lax suits most cookies, including sessions on sites people reach by following links. Strict is tighter but leaves the cookie out when a visitor arrives from another site. None is only for cookies that must work inside other sites, and requires Secure.
- Why does the checker show no cookies for my site?
- The home page did not set any. Many sites set cookies only after sign-in, or on the application's own host, which this check does not visit.
Related security tools
- HSTS checker - Check Strict-Transport-Security: max-age, includeSubDomains, preload and the HTTP redirect.
- Content Security Policy checker - Read a site's Content-Security-Policy directive by directive and spot unsafe inline scripts.
- HTTP security headers checker - Check a site's HSTS, CSP, framing, content-type, referrer and permissions headers.