Skip to main content
Version: Latest (1.1.0)

Reports & Analysis

The Report view audits every cookie on the site in one place: a health score, a list of severity-ranked findings with concrete fixes, and supporting breakdowns for coverage, scope, expiry, and size. Save a snapshot and Cookie Lens tracks how the score moves over time.

The Health Score​

Cookie Lens scores the site's cookies out of 100. Each finding carries a severity — High, Medium, Low, or Info — and weightier, more common problems pull the score down more. A higher score means fewer and less severe issues.

Findings​

Findings span security, privacy, and hygiene. Representative checks:

Security​

  • Sensitive cookie missing HttpOnly — a session/auth cookie readable by JavaScript (XSS exposure).
  • SameSite=None without Secure — a cross-site cookie sent insecurely.
  • Prefix violation — a __Secure- or __Host- name that doesn't meet the prefix's requirements.
  • alg:none JWT — an unsigned token accepted as-is.
  • Weak or unspecified SameSite — consider setting Lax or Strict explicitly.

Privacy​

  • Third-party cookies — set by a domain other than the site.
  • Tracking id / PII — values that look like tracking identifiers or personal data.
  • Unpartitioned cross-site cookies — cookies that could be read across sites.

Hygiene & size​

  • Over 4096 bytes — larger than the per-cookie limit; the browser rejects it.
  • Domain carrying too many / too-large cookies — approaching per-domain limits.
  • Duplicate names, expired, and very long-lived cookies.

Rejected Cookies​

Not every Set-Cookie header becomes a cookie — the browser silently drops some, with nothing in the console. Cookie Lens surfaces these in the Activity feed, tagged Rejected, with the exact reason:

  • __Host- requirements not met — needs Secure, Path=/, and no Domain.
  • Invalid domain — the Domain attribute isn't allowed for the setting host.
  • Blocked as third-party — dropped under third-party cookie restrictions; add Partitioned (CHIPS) if it's meant to work cross-site.

That turns a cookie that "won't set" from a guessing game into a labeled event.

Rolling Expiry​

Some cookies never actually expire: the server pushes their expiration forward on every visit, so the lifetime keeps sliding and the cookie effectively lives forever — a persistence and tracking vector even when the value rotates each visit. Cookie Lens flags these with a Rolling / Sliding badge in the list and a Rolling expiry finding in the Report. The fix is server-side: delete it, or give it a real, bounded lifetime.

If the page uses a supported consent manager — OneTrust, Cookiebot, CookieYes, Didomi, or IAB TCF (euconsent-v2) — Cookie Lens reads its cookie to learn which categories the user accepted or rejected and when consent was recorded, then checks the jar against that decision:

  • Set despite rejection — cookies present for a category the user rejected.
  • Written before consent — non-essential cookies set before the consent moment.
  • Couldn't classify — cookies it can't auto-categorize by name; review these manually.

Strictly-necessary and functional cookies aren't flagged — only analytics and advertising. If no known consent-manager cookie is found but several analytics cookies are present, that's called out too.

Enter a request URL and Cookie Lens shows which of the current cookies your browser would actually attach to it — and, for each one it wouldn't, why:

  • Sent — would be attached to the request.
  • Link clicks only — sent on top-level navigation but not on background fetch/XHR, because of SameSite=Lax.
  • Not sent — with the reason: domain or path mismatch, a Secure cookie over plain HTTP, expired, SameSite=Strict/Lax on a cross-site request, or partitioned to a different top-level site.

It answers "why isn't my cookie being sent to this API?" without trial and error.

Supporting Breakdowns​

Beyond the findings list, the Report shows:

  • Coverage — what share of cookies set Secure, HttpOnly, and an explicit SameSite.
  • Scope — first-party vs third-party counts.
  • Expiry distribution — session vs persistent, bucketed by lifetime.
  • Per-domain size — total bytes and count per domain, against browser limits.

Save a Report snapshot, make changes, and re-open the Report: it compares against the last snapshot and shows which findings appeared or cleared and how the score moved — useful for tracking a hardening effort or catching a regression.

How to Improve a Score​

  1. Start with High-severity findings — they hurt the most and usually matter the most.
  2. Click a finding to see the affected cookie and the recommended fix.
  3. Edit the cookie to apply the fix (enable HttpOnly, add Secure, tighten SameSite, shrink an oversized value). See Editing Cookies.
  4. Freeze a cookie you've just hardened if the server keeps reverting it, so the fix holds while you verify. See Freezing Cookies.
  5. Re-open the Report to confirm the finding cleared and the score rose.

See Also​