SSL & Security

Cookie Security Checker

Set-Cookie Attributes

Audit a site's cookie flags

We'll request the page over HTTPS and inspect every Set-Cookie header for the Secure, HttpOnly, SameSite, Path, Domain and expiry attributes. Cookie values are never read back.

Try:
github.com
wikipedia.org
bbc.com

Tool features

Complete Set-Cookie attribute analysis with prioritised fixes
4 checks

Every Set-Cookie Header

Reads cookies from the whole redirect chain, not just the final page

Attribute Analysis

Secure, HttpOnly, SameSite, name prefixes, scope and expiry per cookie

Purpose-Aware Grading

Session and auth cookies are held to a stricter standard than preferences

Security Score

An overall score out of 100 with prioritised, specific fixes

What cookie attributes do & why they matter

How Secure, HttpOnly and SameSite protect a session

A cookie is only as safe as the attributes it is set with. The Set-Cookie header carries flags that decide whether a browser will send the cookie over plain HTTP, hand it to JavaScript, or attach it to requests started by another site. Get them wrong and a session cookie becomes a credential anyone can lift.

This tool requests the page the way a browser does, follows the redirect chain, and reads every Set-Cookie header along the way — including the ones set on a 302 during a login flow. It grades each cookie against the attributes its purpose actually requires: a session cookie without HttpOnly is a serious finding, the same omission on a language preference is not.

Cookie values are credentials, so they never leave the server. Only names, attributes and value lengths are reported, and the raw header is shown with the value replaced by <redacted>.

Secure
The browser only ever sends the cookie over HTTPS, never plain HTTP.
HttpOnly
Hides the cookie from document.cookie, so injected script cannot read it.
SameSite
Controls whether the cookie rides along on cross-site requests (Lax, Strict, None).
__Host- prefix
Browsers reject the cookie unless it is Secure, Path=/ and has no Domain.

How to use this tool

Audit a site's cookie attributes in four steps
1
Enter a domain or URL
Type a hostname or a full page URL, e.g. example.com or https://example.com/login.
2
Run the check
Click Check Cookies to request the page over HTTPS and read every Set-Cookie header it returns.
3
Review each cookie
See the attributes present on each cookie, which protective flags are missing, and how exposed that leaves it.
4
Apply the fixes
Work through the recommendations, then re-check to confirm the corrected attributes are being served.

Related tools

Keep debugging with tools from the same suite
5 tools
Secure Header Checker
Check security headers like CSP, HSTS, X-Frame-Options, and more with security scoring
OCSP Checker
Check SSL certificate revocation status using the Online Certificate Status Protocol (OCSP)
HSTS Checker
Check HTTP Strict Transport Security (HSTS) header configuration and preload status
HTTP Header Checker
Analyze HTTP response headers for any website or URL with detailed header information
X-Frame Options Checker
Check X-Frame-Options header to prevent clickjacking attacks and iframe embedding

Frequently asked questions

Common questions about cookie security
6 Q&A

A cookie is insecure when it lacks the attributes its purpose requires: Secure (so it is never sent over plain HTTP), HttpOnly on session and auth cookies (so scripts cannot read it), and an explicit SameSite value (so cross-site behaviour is your decision rather than the browser default).

No. The server reads the Set-Cookie headers, extracts the name and attributes, and discards the value immediately. Values are never returned to the browser, stored, exported or included in a share link — the raw header is shown with the value replaced by .

Most sites only issue a session cookie once you interact with them. Check the URL that actually starts a session — a login page or a page behind authentication — rather than the public landing page, and the cookie will show up in the report.

Lax is the right baseline for most cookies and is what browsers now default to. Use Strict for session cookies that never need to survive a cross-site navigation. Use None only for genuine cross-site flows such as embedded widgets or SSO, and it must be paired with Secure or browsers reject the cookie.

It turns cookie hygiene into something the browser enforces. A cookie named with the __Host- prefix is only accepted if it is Secure, has Path=/ and carries no Domain attribute — so it cannot be set by a subdomain or scoped loosely, even by mistake.

As briefly as the feature allows. Session cookies that expire on browser close are safest for authentication. Chrome and Firefox cap any cookie lifetime at 400 days, so longer expiries are silently truncated, and cookies persisting over a year are long-lived identifiers with consent obligations.