{{ summary.heading }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
Examples: https://portal.example.com, auth callback response, or staging login.
First-party apps usually prefer explicit Lax or Strict; embedded and SSO flows need deliberate None with Secure only for the cookies that cross sites.
{{ sourceStatusLine }}
Flag missing HttpOnly on session-like cookies
CSRF-token cookies can be intentionally readable by JavaScript; auth/session cookies should usually be HttpOnly.
Warn on Domain-scoped cookies
Domain-scoped cookies are still same-site across subdomains, so every covered subdomain must be trusted.
Warn when Path is omitted
Path is not a security boundary, but explicit paths make cookie scope easier to audit across login and logout responses.
Severity Cookie Signal Evidence Recommended action Copy
{{ row.severityLabel }} {{ row.cookie }} {{ row.signal }} {{ row.evidence }} {{ row.recommendation }}
Cookie Role SameSite Secure HttpOnly Scope Status Copy
{{ row.cookie }} {{ row.role }} {{ row.sameSite }} {{ row.secure }} {{ row.httpOnly }} {{ row.scope }} {{ row.status }}
Paste Set-Cookie headers to build the inventory.
Cookie Same-site request Cross-site top-level safe Cross-site unsafe request Cross-site embedded request Delivery note Copy
{{ row.cookie }} {{ row.sameSiteRequest }} {{ row.crossSiteSafe }} {{ row.crossSiteUnsafe }} {{ row.crossSiteEmbedded }} {{ row.note }}
Paste Set-Cookie headers to model delivery behavior.
Paste Set-Cookie headers to build the coverage chart.
Tags: HTTP, Security
Export to PDF Fullscreen
Customize
Advanced
:

SameSite is a cookie attribute that tells browsers when a cookie should travel with requests that start from another site. It matters most for session cookies, login callbacks, payment returns, embedded widgets, and CSRF protection because the wrong setting can either send sensitive state too broadly or break a flow that depends on cross-site delivery.

A cookie with SameSite=Strict is held back from cross-site navigation. SameSite=Lax keeps normal same-site behavior and allows top-level safe navigation, but blocks embedded requests and most unsafe cross-site requests. SameSite=None opts into cross-site delivery, which modern browsers require to be paired with Secure.

SameSite cookie review flow from Set-Cookie headers through expected context and attribute checks to delivery findings and score

SameSite is not a complete CSRF defense. It reduces when browsers attach cookies, but applications still need server-side CSRF checks, careful origin handling, authentication, authorization, and separate treatment for sensitive actions. Cookie attributes are also read by browsers, proxies, and frameworks from the actual delivered response, so copied documentation or framework settings are weaker evidence than the response users receive.

Useful review starts by matching the cookie's purpose to the request context. A first-party session usually does not need SameSite=None. A payment or identity-provider callback may need it for only one short-lived state cookie. An embedded widget cannot rely on Lax if it needs cookie state inside an iframe or subresource request.

Technical Details:

SameSite compares the site that owns the cookie with the site that initiated the request. The site comparison is based on the registered domain and scheme, so subdomains under the same registered domain can still be same-site even when their hostnames differ. That is why a broad Domain attribute deserves review for session cookies: SameSite does not stop all covered subdomains from receiving the cookie.

The three SameSite values describe delivery behavior, not the sensitivity of the cookie value. Strict is the narrowest option and can break external-link continuity. Lax is a common first-party session default because it permits top-level safe navigation while blocking embedded cross-site requests. None deliberately permits cross-site delivery and must be used with Secure.

Rule Core

The checker reads one or more Set-Cookie headers, extracts each cookie's attributes, infers a cookie role from the name, and compares the result with the selected expected use. Status lines are skipped, folded continuation lines are joined, non-cookie header lines are reported as parsing notes, and cookie-like name=value lines are accepted when a prefix is absent.

Cookie state Same-site request Cross-site top-level safe Cross-site unsafe or embedded Review note
SameSite=Strict Sent Blocked Blocked Strong for first-party state, but too narrow for SSO, payment returns, widgets, and external-link continuity.
SameSite=Lax Sent Sent Blocked Common for normal sessions; can break POST callbacks, fetch callbacks, iframes, images, scripts, and widget state.
SameSite=None; Secure Sent Sent Sent when browser policy permits Required for deliberate cross-site cookie delivery; should be limited to cookies that truly need it.
Missing SameSite Sent Sent by default Lax Mostly blocked Relies on browser defaults and possible recent-cookie compatibility behavior instead of explicit policy.
Invalid SameSite Default behavior Default behavior Default behavior Values outside Strict, Lax, and None fall back to browser default enforcement.

Several findings come from cookie attributes that are separate from SameSite but change whether the policy is trustworthy. Secure protects transport for HTTPS cookies. HttpOnly keeps session-like cookies away from browser JavaScript. Path narrows request matching but is not a security boundary. Prefixes such as __Secure- and __Host- assert attribute requirements that supporting browsers can enforce.

Signal When it is raised Typical correction
Missing or invalid SameSite The cookie omits SameSite or uses a value other than Strict, Lax, or None. Set an explicit SameSite value that matches the cookie's actual request path.
SameSite=None without Secure A cookie opts into cross-site delivery without the transport flag required by modern browsers. Add Secure and serve the response over HTTPS, or use Lax or Strict when cross-site delivery is not needed.
Context mismatch Strict or Lax is chosen for SSO, payment, or embedded use, or None appears on a first-party or high-risk action cookie. Separate first-party session cookies from callback, transaction, or widget cookies and give each one the narrowest working policy.
Missing hardening flag A session-like or application cookie is missing Secure or, when enabled, missing HttpOnly. Add Secure for HTTPS cookies and use HttpOnly for server-only state.
Scope and prefix issue A cookie uses Domain, omits Path when path warnings are enabled, uses Partitioned without Secure, duplicates attributes, or violates __Host-, __Secure-, __Http-, or __Host-Http- rules. Prefer host-only session cookies, emit each attribute once, and make the prefix match the actual Secure, HttpOnly, Domain, and Path attributes.

Score and Severity Logic

Each cookie receives severity-weighted findings. The coverage score is the remaining percentage after those weights are subtracted, capped at a full 100-point penalty per cookie. The page score is the rounded average coverage score across all parsed cookies.

cookie coverage = max ( 0 , 100 - min ( 100 , ∑ finding weight ) )
Severity Weight Typical meaning
Critical 40 Malformed cookie syntax or SameSite=None without Secure.
High 26 Session cookies without key hardening, policy choices that block required cross-site flows, non-secure origins, and prefix violations.
Medium 14 Missing explicit SameSite in first-party contexts, broader-than-needed None, Domain-scoped session cookies, and application cookies missing HttpOnly.
Low 6 Cleanup findings such as duplicate attributes, optional Path omissions, or Strict-vs-Lax tuning for high-risk session cookies.
Info 0 Notes such as a JavaScript-readable CSRF token cookie, where the right choice depends on the application's token pattern.

The delivery model is deliberately conservative and header-focused. It does not prove that a session is exploitable or that an identity flow will succeed in every browser. It shows how the pasted cookie attributes line up with modern browser rules and the expected use selected for the review.

Everyday Use & Decision Guide:

Start with one response that sets the cookies you want to review. Put the production origin or release label in Site URL or label, choose Expected cookie use, and paste the captured Set-Cookie lines into Set-Cookie headers. If the source is copied from DevTools, a proxy, or curl -i, status lines can stay in the paste because they are ignored.

Use First-party app session for normal login state, preferences, and app cookies. Choose Cross-site SSO or payment return when a provider redirects or posts back to the site. Choose Embedded iframe, widget, or pixel when the cookie must be available inside a third-party embed. Use High-risk first-party action for step-up, transaction, admin, password-change, or similar state where broad cross-site delivery should slow the review.

  • Use Strong sample and Problem sample to compare expected output shapes before reviewing a real response.
  • Use Normalize after pasting a mixed response block so every parsed cookie is shown as a separate Set-Cookie line.
  • Use Browse TXT or drop a small text capture when the response has many cookies; files over 1 MiB are rejected.
  • Keep Flag missing HttpOnly on session-like cookies enabled unless client-side code must read that specific cookie.
  • Keep Warn on Domain-scoped cookies enabled for session reviews because subdomains covered by Domain are still same-site.
  • Enable Warn when Path is omitted when login, logout, callback, and account routes need consistent scope documentation.

The safest reading path is the summary, then Policy Findings, then Cookie Inventory, then Delivery Matrix. The summary shows the score, cookie count, explicit SameSite count, None plus Secure count, and selected context. Policy Findings gives the action rows. Cookie Inventory confirms roles, attributes, and scope. Delivery Matrix shows which request types would send or block each cookie.

Do not treat a clean score as proof that CSRF protection is complete. It means the pasted cookies did not trigger the checked SameSite, transport, scope, prefix, and hardening findings for the selected expected use. Confirm the server-side CSRF token pattern, actual callback method, deployed HTTPS behavior, and every response that sets or refreshes the same cookie.

Step-by-Step Guide:

Review one cookie-setting response at a time so the findings, inventory, delivery rows, chart, and JSON all describe the same browser behavior.

  1. Enter Site URL or label. Use an HTTPS origin such as https://portal.example.com/login when transport behavior matters; a non-URL label is treated as an HTTPS production sample and adds a parsing note.
  2. Choose Expected cookie use. The choice changes recommendations for Strict, Lax, and None, especially for SSO callbacks, embeds, and high-risk action cookies.
  3. Paste one or more Set-Cookie lines into Set-Cookie headers, or load a small text file with Browse TXT. The source hint should show the number of parsed cookies and characters.
  4. If Parsing notes appears, fix ignored lines, malformed name/value pairs, or a non-URL site label before relying on the score. Normalize can rebuild the parsed cookie lines from a copied response block.
  5. Open Advanced and set the three switches to match the review. Missing HttpOnly and Domain-scope warnings should usually stay enabled for session cookies.
  6. Read the top summary. A primary value such as 1 critical or 2 high means severe findings are present; a value such as 92/100 means no critical or high finding is driving the headline.
  7. Open Policy Findings and work from the highest severity row down. Use Evidence to confirm the exact attribute issue and Recommended action as the remediation note.
  8. Open Cookie Inventory to confirm that role, SameSite, Secure, HttpOnly, Domain, Path, Partitioned, lifetime, and status match the cookie you intended to review.
  9. Open Delivery Matrix for cross-site behavior. A widget cookie that shows Blocked under embedded requests needs SameSite=None; Secure, while a first-party session that shows broad cross-site delivery may need Lax or Strict.
  10. Use Cookie Attribute Coverage when many cookies are present. A large remediation gap for one cookie points back to its Policy Findings row and helps prioritize release cleanup.

A useful handoff has no Critical or High rows, Cookie Inventory matching the captured response, Delivery Matrix matching the intended flow, and JSON or table exports that have been scrubbed before sharing outside the review team.

Interpreting Results:

The first Critical or High row carries more weight than the average score. SameSite=None without Secure, Strict blocks selected cross-site flow, Lax blocks embedded delivery, Session-like cookie missing HttpOnly, or a prefix violation usually names the next change directly.

Visible cue Best first reading What to verify next
Critical for SameSite=None The cookie asks for cross-site delivery but lacks Secure. Add Secure on HTTPS, or switch to Lax or Strict if cross-site delivery is not needed.
High on SSO or embedded use The SameSite value may block the selected flow. Confirm whether the callback uses POST, fetch, iframe, image, script, or top-level safe navigation.
Domain-scoped cookie The cookie can reach matching subdomains, which SameSite still treats as same-site in many cases. Prefer a host-only session cookie unless every covered subdomain is trusted and controlled.
Default Lax The cookie omits SameSite and relies on browser default behavior. Set an explicit Lax, Strict, or None; Secure policy so the response declares intent.
Pass baseline row No checked SameSite or hardening issue was found for the selected context. Repeat the check on login, refresh, callback, logout, and error responses that set the same cookie name.

The chart is a prioritization aid. A cookie with a high coverage score can still deserve a code review if it carries account state, and a low score may come from several cleanup findings rather than one exploitable issue. Policy Findings gives the exact evidence that should drive the fix.

Cookie values are not needed for policy review. Replace real session tokens with short placeholders before sharing exports, and verify the attributes from the actual response again after the server or proxy change is deployed.

Worked Examples:

First-party login response

A production login response sets __Host-session=abc; Path=/; Secure; HttpOnly; SameSite=Lax, csrf_token=def; Path=/; Secure; SameSite=Strict, and preferences=theme-dark; Path=/; Secure; SameSite=Lax. With Expected cookie use set to First-party app session, the summary can show a high coverage score and Explicit 3/3. Policy Findings may still note the CSRF token as JavaScript-readable if HttpOnly is absent, but the recommendation is to keep server-side CSRF validation rather than blindly hide a token that client code intentionally reads.

Widget state that needs an iframe

An embedded support widget sets widget_state=ghi; Path=/embed; SameSite=Lax; Secure. With Expected cookie use set to Embedded iframe, widget, or pixel, Policy Findings reports Lax blocks embedded delivery, and Delivery Matrix shows Blocked for cross-site embedded requests. The likely fix is a narrowly scoped widget cookie using SameSite=None; Secure, not changing every session cookie to None.

Payment callback using a cross-site POST

A checkout flow sets payment_state=xyz; Path=/checkout; Secure; HttpOnly; SameSite=Lax before sending the user to a payment provider. With Expected cookie use set to Cross-site SSO or payment return, Policy Findings reports Lax may break POST or fetch callbacks. If the provider returns with a top-level GET, Lax may be enough; if it posts back or uses an embedded return, isolate the callback state in a short-lived SameSite=None; Secure cookie.

Prefix and transport cleanup

A copied response contains Set-Cookie: __Host-session=abc; Domain=.example.com; Path=/; SameSite=None for http://portal.example.com. The checker can raise SameSite=None without Secure, Cookie set from non-secure origin, and __Host- prefix has Domain. The clean response needs HTTPS, Secure, no Domain, and a SameSite value chosen for the actual flow.

Responsible Use Note:

Cookie headers can expose session names, auth patterns, subdomain trust choices, callback design, and proxy mistakes. Paste the smallest useful response and replace real cookie values with placeholders when the value itself is not needed for the review.

The analysis runs in the browser session and does not require a backend request. Copied tables, downloaded JSON, chart files, and URL state can still contain sensitive header text, so treat those outputs like security evidence.

FAQ:

Does SameSite replace CSRF tokens?

No. SameSite reduces when browsers attach cookies to cross-site requests, but applications still need server-side CSRF protection, authorization checks, and careful handling for sensitive actions.

Why is SameSite=None without Secure critical?

Modern browsers require Secure when a cookie uses SameSite=None. The checker reports this as Critical because the cookie asks for cross-site delivery but lacks the required transport pairing.

Why does Lax break my embedded widget?

SameSite=Lax is not sent on iframe, image, script, fetch, or other embedded cross-site requests. Use the Embedded iframe, widget, or pixel context and check Delivery Matrix for the embedded column.

Why did the checker treat my site label as HTTPS?

A value without a URL scheme is treated as an HTTPS production sample. Enter a full origin such as http://localhost:8080 or https://portal.example.com when transport behavior should be modeled.

Why did some pasted lines get ignored?

Only Set-Cookie lines and cookie-like name=value lines become cookie evidence. HTTP status lines are skipped, non-cookie headers create parsing notes, and malformed lines should be corrected before using the result.

Does a high score mean the cookie setup is secure?

No. A high score means the pasted cookies avoided the checked findings for the selected context. Repeat the review on every response that sets the cookie and confirm CSRF, authentication, authorization, and deployment behavior separately.

Glossary:

SameSite
A cookie attribute that limits when browsers attach a cookie to requests that begin from another site.
Strict
The SameSite value that sends the cookie only with same-site requests.
Lax
The SameSite value that sends the cookie with same-site requests and top-level safe cross-site navigation.
None
The SameSite value that permits cross-site delivery when paired with Secure.
Secure
A cookie attribute that limits delivery to secure channels such as HTTPS, with localhost exceptions in browsers.
HttpOnly
A cookie attribute that prevents browser JavaScript APIs from reading or writing the cookie.
Domain-scoped cookie
A cookie with a Domain attribute that can be sent to matching subdomains.
Host-only cookie
A cookie without a Domain attribute, scoped to the host that set it.

References: