Cookie Security Analyzer

Server assisted New Internet Security & Privacy

Enter a page URL and the Mutqan server requests it once, with no cookies of its own, and reads the Set-Cookie headers of the response — or paste the headers from your browser's developer tools and nothing is sent. Each cookie is checked against the RFC 6265bis rules browsers enforce, every problem says what the browser will do (reject the cookie, ignore an attribute, shorten its life) and how to fix it, and the page gets an A–F grade.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

Which Set-Cookie attributes protect a session cookie?

Secure keeps the cookie off plain HTTP, HttpOnly hides it from JavaScript so a cross-site scripting bug cannot read it, and SameSite (Lax or Strict) stops browsers from sending it with requests that other sites trigger. The __Host- name prefix makes the browser enforce Secure, Path=/ and no Domain, and a short Max-Age limits how long a stolen value stays useful; RFC 6265bis defines these rules and when a browser rejects a cookie that breaks them.

Security note: A cookie that carries a session is a password for as long as it lives. Never paste production session cookies into tickets or chat; if one has been exposed, end that session on the server.

How to use Cookie Security Analyzer

  1. Enter the page URL, or paste the Set-Cookie headers from your browser's developer tools (Network tab → the request that sets the cookie → Response Headers).
  2. Keep "Follow redirects" ticked to analyse the page you land on; untick it when the cookie you care about is set on a redirect, such as the response to a sign-in form.
  3. Press Analyze cookies, read the grade and the reason for it, then work through the findings from High down to Info.
  4. Compare attributes side by side in the Cookies table, and download either table as CSV for a ticket or an audit report.

Cookie Security Analyzer features

  • Reads the Set-Cookie headers of a live page through the Mutqan server, or a list you paste from your browser's developer tools or curl -I — other response headers in the paste are skipped
  • Checks every cookie against RFC 6265bis: Secure, HttpOnly, SameSite, the __Host- and __Secure- prefixes, Domain and Path scope, Max-Age and Expires, and the 4096-byte and 400-day limits
  • Says what a browser actually does with each problem — rejects the cookie, ignores an attribute or shortens its lifetime — and gives the change that fixes it
  • Recognises session, sign-in and CSRF cookies by their names and holds them to a stricter bar; a CSRF token that scripts must read is not reported as an error for lacking HttpOnly
  • Grades the page from A to F, with caps so that one exposed session cookie cannot hide behind a dozen harmless analytics cookies
  • Masks every value before it is shown or exported: a session id appears as its first and last characters only
  • Treats deletion headers (Max-Age=0 or a past Expires) separately: they are checked for the Domain and Path that make the deletion work, and left out of the grade

Inputs and outputs

Inputs

  • Page URL — an http:// or https:// address; a bare host such as example.com is read as https://. The Mutqan server sends one GET request with a fixed header set that identifies the Mutqan relay (User-Agent MutqanTools-Relay/1.0), and no cookies.
  • Follow redirects — on by default (up to 5 hops); off to analyse the cookies of the first response.
  • Pasted headers — Set-Cookie lines, with or without the "Set-Cookie:" prefix, up to 500 lines; status lines and other headers are skipped. When present, nothing is fetched and the URL only gives the page host and scheme.

Outputs

  • Summary — the grade and score, the number of cookies, how many carry Secure and HttpOnly, how many use SameSite=None and how many headers only delete a cookie.
  • Findings — every issue with its severity, the cookie it belongs to and the change that fixes it, worst first.
  • Cookies — one row per Set-Cookie header: masked value, Secure, HttpOnly, SameSite, scope, path, lifetime in days, size in bytes and the number of issues.
  • Why this grade and Fetch details — the cap that decided the grade; for a fetched page, the final URL, status, redirects followed, the address the host resolved to and the fetch time.

Cookie Security Analyzer example

Five cookies pasted from a sign-in response

Input:

Page URL: https://www.example.com/
Set-Cookie: sessionid=8f2c41d9a7e34b05b1c6e2f09d3a7c18; Path=/; HttpOnly
Set-Cookie: csrftoken=Zq81LmP0aXv3; Path=/; Secure; SameSite=Lax; Max-Age=31449600
Set-Cookie: __Host-prefs=lang%3Den; Path=/; Secure; SameSite=Strict
Set-Cookie: _ga=GA1.1.1234567890.1760000000; Domain=.example.com; Path=/; Max-Age=63072000; SameSite=Lax
Set-Cookie: tracking=abc; SameSite=None; Path=/

Output:

Grade D (81/100) — capped at D: a session-like cookie has a high-severity issue
Cookies 5 · With Secure 2/5 · With HttpOnly 1/5 · SameSite=None 1
High · sessionid · Missing Secure
High · tracking · SameSite=None without Secure — rejected
Medium · sessionid · No SameSite attribute
Medium · _ga, tracking · Missing Secure
Low · _ga · Domain shares the cookie with every subdomain · Lifetime longer than 400 days
Info · csrftoken · Eligible for the __Host- prefix
sessionid value shown as 8f2…c18

How to read the Cookie Security Analyzer results

High means the browser rejects the cookie or a session cookie is exposed (no Secure, no HttpOnly, an invalid prefix, a public-suffix Domain): fix these first. Medium weakens protection (no SameSite, a session cookie sent cross-site, a long-lived session). Low and Info are hygiene and hints.

A grade of A means every live cookie is close to best practice for what a header can show. It says nothing about how the server creates, rotates or invalidates sessions.

"Rejected" in a finding means the browser does not store the cookie at all: whatever depends on it is already broken in that browser, even if the site seems to work in another.

"No Set-Cookie headers" on a fetched page is common: many sites set cookies only after sign-in, after consent, or from JavaScript. Analyse the response that sets the cookie you care about.

A cookie without SameSite is treated as Lax by Chromium-based browsers, while Safari and Firefox still send it cross-site in some flows, so its behaviour differs by browser; setting the attribute removes the doubt.

When to use Cookie Security Analyzer

  • Checking that a new sign-in flow sets its session cookie with Secure, HttpOnly and SameSite before release.
  • Reviewing analytics and advertising cookies for SameSite=None without Secure, which browsers silently drop.
  • Writing a penetration-test or audit finding that names the missing attribute and the rule that requires it.
  • Confirming that a logout response really deletes the session cookie, with a Domain and Path that match the original.

Troubleshooting

  • "No Set-Cookie header was found in the pasted text": copy the response headers, not the request headers, of the request that sets the cookie. In DevTools, select the request, open Headers and copy the Response Headers section.
  • The fetched page shows no cookies although your browser has some: they may be written by JavaScript, set by another request of the page, set after a consent banner, or only for signed-in users. Paste the headers of that response instead.
  • "This address cannot be reached from the Mutqan server": the host resolves to a private or reserved address, or the server's safety rules refuse it. An internal site can still be checked by pasting its headers.
  • Domain-match and Secure-over-HTTP checks are missing in paste mode: enter the page URL as well. It is used only as context; nothing is fetched.

Frequently asked questions about Cookie Security Analyzer

Why is my cookie marked "rejected"?

Because a browser would not store it at all: SameSite=None without Secure, a __Host- or __Secure- prefix whose rules are not met, a Domain that does not cover the page host or is a public suffix, a Partitioned cookie without Secure, or a name and value over 4096 bytes. The finding names the rule; until it is fixed, whatever relies on that cookie does not work in that browser.

Which cookies count as session cookies?

Those whose names contain a session, sign-in or token word as a whole part of the name — session, sid, auth, token, jwt, login, remember, refresh, csrf — including compounds such as JSESSIONID, PHPSESSID, connect.sid or laravel_session. They are held to a stricter bar, because exposing them exposes the account. A name is only a hint: rename nothing for the tool's sake.

Do I need HttpOnly on a CSRF token cookie?

Not if your front end reads it to send it back in a header (the double-submit pattern); that is why a CSRF cookie without HttpOnly is shown as Info rather than as an error. If only the server compares the token, add HttpOnly.

Why does the fetched page show no cookies when my browser has many?

The Mutqan server makes one request with no cookies and no sign-in. Cookies set by JavaScript, by other requests of the page, after a consent banner or only after sign-in do not appear in that response. Copy the Set-Cookie headers of the response you care about from your browser's developer tools and paste them instead.

Are my cookie values sent or stored anywhere?

In paste mode the analysis runs entirely in your browser. In URL mode the server fetches the page and returns its headers to your browser without storing them. Either way, values are masked before they are displayed or exported.

What does "Eligible for the __Host- prefix" mean?

The cookie already has Secure, Path=/ and no Domain. Renaming it to __Host-name makes browsers enforce those rules, so a subdomain or a plain-HTTP response can never overwrite it. It is a recommendation, not a fault.

Technical notes

Parsing follows RFC 6265bis (draft-ietf-httpbis-rfc6265bis, the revision of RFC 6265 that browsers implement): attribute names are case-insensitive, the last occurrence of an attribute wins, Expires is read with the cookie-date algorithm of RFC 6265 §5.1.1 rather than a general date parser, and Max-Age takes precedence over Expires.

Browser rules applied: a Secure cookie cannot be set from an http:// page; SameSite=None requires Secure; __Secure- requires Secure, and __Host- also requires Path=/ and no Domain (prefixes match case-insensitively); a Domain must domain-match the page host and must not be a public suffix (checked against the bundled Public Suffix List); a name and value over 4096 bytes is rejected and an attribute value over 1024 bytes is ignored; lifetimes are capped at 400 days; a Partitioned (CHIPS) cookie must be Secure.

Scoring: each live cookie starts at 100 and loses 25 per high, 10 per medium and 3 per low issue; the page score is the average, minus 5 for each duplicated name and 10 for more than 50 cookies on one domain. A is 90 or more, B 75, C 60, D 40, F below 40. Caps: F when a session-like cookie has neither Secure nor HttpOnly; D when session cookies are set over HTTP or a session cookie has a high issue; C when any cookie has a high issue.

Session-like names are recognised word by word (sid, session, auth, token, jwt, login, remember, refresh, csrf, xsrf, and compounds such as JSESSIONID, PHPSESSID or connect.sid), so names such as sidebar_state or device_id are not mistaken for session cookies.

Limitations and methodology

Only cookies set by HTTP response headers are seen. Cookies written by JavaScript, set by other requests of the page (scripts, images, API calls) or by third-party frames are invisible to a single page request.

The request comes from the Mutqan server on Cloudflare's network, as a first-time visitor with no cookies and no sign-in. A site may set different cookies for a real browser, a region, a signed-in user or after consent, and some sites challenge automated requests.

With redirects followed, cookies set on the intermediate responses are not returned; untick "Follow redirects" to read the first response.

The grade covers what a header can show. Session fixation, token randomness, server-side expiry and CSRF defences cannot be tested from cookie attributes.

Security and privacy

In URL mode the URL goes to the Mutqan server, which makes one GET request to that page and returns its response headers to your browser; nothing is stored. In paste mode the headers never leave your browser.

Pasted headers can contain live session ids. Values are masked before they are displayed or exported, but treat the pasted text as a secret, and sign out or rotate the session if it came from production.

References