{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ computation.values.score }}/100 {{ computation.values.cookie_count }} cookies {{ computation.values.blocking_count }} blocking
Use one cookie per line or paste complete response headers. Cookie values never appear in the result tables.
{{ sourceStatus }}
Parsing note: {{ computation.values.parse_warnings[0] }}
A real HTTP URL enables transport checks. A short non-URL label is treated as an HTTPS production review.
The selected use determines whether Strict, Lax, or None can deliver the cookie where the flow needs it.
On is the standing baseline. CSRF-token cookies remain an informational exception because client code may intentionally read them.
{{ requireHttpOnlyBool ? 'On' : 'Off' }}
On is the standing baseline because SameSite does not make every same-site subdomain equally trustworthy.
{{ warnDomainScopeBool ? 'On' : 'Off' }}
Off is neutral because Path omission does not change SameSite enforcement and Path is not a security boundary.
{{ warnMissingPathBool ? 'On' : 'Off' }}
PriorityCookieFindingEvidenceRecommended actionCopy
{{ row.severity_label }}{{ row.cookie }}{{ row.title }}{{ row.evidence }}{{ row.fix }}
CookieRoleSameSiteSecureHttpOnlyScopeStatusCopy
{{ row.cookie }}{{ row.role }}{{ row.same_site }}{{ row.secure }}{{ row.http_only }}{{ row.scope }}{{ row.status }}

Request-context delivery matrix

CookieSame-site requestCross-site top-level safeCross-site unsafeCross-site embeddedDelivery noteCopy
{{ row.cookie }}{{ row.same_site_request }}{{ row.cross_site_safe }}{{ row.cross_site_unsafe }}{{ row.cross_site_embedded }}{{ row.note }}
CSP Header Policy Checker Check a Content-Security-Policy header for risky script sources and missing baseline directives, with reporting and rollout blockers explained.
HTTP Security Headers Checker Audit pasted HTTP security headers for browser policy, session protection and exposure risks with local scoring and a prioritized fix order.
HAProxy Backend Config Generator Build an HAProxy backend block from server rows with health checks and TLS trust choices, then review capacity limits and deployment warnings.
Hypertext Transfer Protocol (HTTP) Header Checker Check a public URL’s HTTP headers across redirects and review security, cache behavior, browser state and cross-origin exposure.

Cookies carry state between HTTP requests, including sessions, preferences, callback state, and anti-forgery tokens. The SameSite attribute tells a browser when a cookie may accompany requests that originate from another site. The right setting depends on the request flow, not on a universal preference for the strictest label.

SettingTypical deliveryCommon fit
StrictSame-site requests onlyAction-sensitive state that does not need external-link continuity
LaxSame-site requests and cross-site top-level safe navigationOrdinary first-party sessions
None; SecureCross-site requests when other browser policy permitsState required by an embedded flow or cross-site callback

“Same-site” is broader than “same-origin.” Related subdomains can be same-site even though they are different origins, which is why broad domain scope and trust between subdomains still matter. SameSite also provides only one defense against cross-site request forgery (CSRF); state-changing requests still need server-side authorization and anti-forgery controls.

Cross-site authentication, payment returns, and embedded widgets create a real tradeoff. Strict or Lax can break the required return path, while None exposes the cookie to more cross-site request contexts. A safer design isolates the smallest amount of short-lived callback or embed state instead of widening every session cookie.

Cookie delivery also depends on Secure, HttpOnly, host and path scope, browser third-party-cookie policy, and newer partitioned-storage rules. A header can look reasonable in isolation and still fail in the browser or give a script, sibling subdomain, or cross-site request more access than intended.

How to Use This Tool:

Review response headers against the flow they are expected to support, not against a generic cookie checklist.

  1. Paste one or more Set-Cookie headers, or load a local text capture. Use one header per logical line.
  2. Enter the production site URL when possible and choose the Expected cookie use: first-party session, cross-site return, embedded widget, or high-risk first-party action.
  3. Keep the session HttpOnly and broad Domain reviews enabled unless the application has a documented exception. Turn on the missing-Path review only when explicit path scope is part of the policy.
  4. Address critical and high findings first, then compare each cookie's modeled delivery with the real login, callback, embed, or transaction flow.

Interpreting Results:

The status is driven by finding severity. Any critical finding produces Critical cookie policy issue; otherwise a high finding produces Cookie hardening required. Lower findings produce Cookie policy findings remain, while no configured rule hit produces Selected baseline aligned.

The score is a transparent triage heuristic, not a browser standard or compliance grade. Read the finding title, evidence, and fix for each cookie. A high score can still hide a flow the selected context did not model, and SameSite=None; Secure can still be blocked by third-party-cookie or storage policy.

Confirm the final behavior in supported browsers over the real HTTPS flow. For authentication and payment paths, test both successful returns and rejected cross-site requests before release.

Technical Details:

A policy review first parses each cookie pair and its attributes, then evaluates delivery, transport, script access, prefix promises, and scope against the selected context. Duplicate attributes use their last parsed value but remain a review finding because the header is ambiguous to people and may be handled differently by surrounding systems.

Rule Core:

ConditionSeverityReason
Malformed name-value pairCriticalNo reliable cookie can be modeled.
SameSite=None without SecureCriticalThe cookie is rejected.
Missing or invalid SameSiteMedium or highDefault enforcement applies; cross-site flows receive the higher finding.
Strict for SSO or embed, or Lax for embedHighThe selected cross-site flow is blocked.
Lax for an SSO returnMediumSafe top-level navigation can work, but a POST or fetch callback may not.
None for first-party or high-risk stateMedium or highCross-site delivery is broader than the selected need.
Session-like cookie missing Secure or required HttpOnlyHighTransport or script access is too broad for authentication state.
Partitioned without SecureHighPartitioned cookie storage requires secure delivery.

Prefix checks enforce the promises carried by cookie names. __Secure- requires Secure. __Host- also requires Path=/ and no Domain. __Http- requires Secure and HttpOnly; __Host-Http- combines the host-only and HTTP-only requirements.

Optional hardening rules flag a broad Domain, an omitted Path, or duplicate attributes. A CSRF-named cookie without HttpOnly receives an informational note because double-submit designs may intentionally expose that token to JavaScript.

Formula Core:

Each cookie begins at 100 points. Findings subtract fixed weights, with the per-cookie penalty capped at 100. Critical, high, medium, and low findings subtract 40, 26, 14, and 6 points respectively; informational findings subtract 0.

Si =max(0,100−min(100,∑jwij)) Score =round(∑iSin)

Here Si is one cookie's score, wij is a finding weight, and n is the number of parsed cookies. A cookie with one high and one low finding scores 68; a second cookie with one medium finding scores 86. Their displayed average is round((68 + 86) / 2) = 77.

The score badge changes presentation below 55, from 55 to below 75, from 75 to below 90, and at 90 or higher; the written status remains severity-driven.

Modeled Delivery:

Strict is modeled as same-site only. Lax also permits cross-site top-level safe navigation, while unsafe callbacks and embedded requests remain blocked. None; Secure permits all modeled request contexts, subject to other browser policy. A missing or unknown value uses default enforcement rather than being treated as an explicit mode.

Privacy and Accuracy Notes:

Header text and local files are parsed in the browser. Even so, use redacted cookie values because copied headers may contain active session identifiers.

  • The site URL supplies an HTTPS or HTTP review context; it does not trigger a network request. A non-URL review label is treated as an HTTPS production context and produces a warning.
  • The delivery table is a policy model, not a browser automation run or a full public-suffix, storage-access, or third-party-cookie simulation.
  • Header source is limited to 100,000 characters. Path limits when a cookie is sent but is not a security boundary between applications on the same host.

Worked Examples:

Cross-site POST callback

A session cookie marked SameSite=Lax may survive a top-level GET return but not a typical cross-site POST callback. Selecting Cross-site SSO or payment return produces a warning so the callback can use narrowly scoped None; Secure state instead of widening the main session unnecessarily.

Host-only session cookie

__Host-session=...; Path=/; Secure; HttpOnly; SameSite=Lax aligns with the first-party baseline. Adding a Domain attribute breaks the __Host- promise and produces a high finding even though SameSite=Lax is unchanged.

References: