SameSite Cookie Policy Checker

Site URL or label:

Examples: https://portal.example.com, auth callback response, or staging login.

Expected cookie use:

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.

Set-Cookie headers:

Parsing notes

{{ warning }}

Session HttpOnly check:

CSRF-token cookies can be intentionally readable by JavaScript; auth/session cookies should usually be HttpOnly.

Domain scope warnings:

Domain-scoped cookies are still same-site across subdomains, so every covered subdomain must be trusted.

Path omission warnings:

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.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Cookie delivery failures often look like application bugs: a login disappears after an identity-provider return, a payment callback loses its state, an embedded widget cannot recognize the user, or a security review finds session cookies traveling farther than intended. The browser makes the delivery decision before application code runs. It reads the cookie attributes, compares the current request with the site that set the cookie, and decides whether the cookie belongs on that request at all.

SameSite is the attribute that declares how much cross-site delivery is intended. It is easy to confuse "same-site" with "same-origin", but they are not the same boundary. Same-site matching is based on the scheme and registrable domain, so two subdomains can be same-site even when they are different origins. That distinction matters when marketing pages, admin apps, APIs, and customer portals live under related hostnames but have different trust levels.

First-party request: A request made while the user is already on the same site as the cookie. Normal app navigation and same-site API calls fall here.
Cross-site top-level navigation: A visible browser navigation from another site, such as clicking a link or returning from an identity provider.
Cross-site unsafe request: A cross-site request that changes state, such as many POST callbacks. Lax delivery is usually not enough for this pattern.
Embedded cross-site request: A request made inside an iframe, image, script, fetch, widget, or pixel. These flows need explicit cross-site cookie intent and may still face third-party cookie restrictions.

SameSite=Strict is the narrowest choice. It is useful for high-risk first-party state because external navigation does not bring the cookie along. SameSite=Lax is common for login sessions because it works for ordinary same-site use and many link returns, but it does not cover iframes, fetch callbacks, images, scripts, or most cross-site POST flows. SameSite=None opts into cross-site delivery and must be paired with Secure in modern browsers.

Leaving SameSite out is not the same as making an active decision. Modern browsers generally treat missing SameSite as Lax, and some compatibility behavior can make recent cookies behave differently on certain top-level unsafe navigations. Explicit attributes make audits easier because the response states its intent instead of relying on browser defaults.

SameSite is defense in depth, not a full CSRF design. Sensitive actions still need server-side CSRF tokens or equivalent protections, origin checks where appropriate, authorization checks, safe HTTP method discipline, and XSS prevention. A cookie can have a good SameSite value and still be too broad because of its Domain, missing Secure transport, missing HttpOnly on session material, or a prefix that promises stronger rules than the header actually provides.

How to Use This Tool:

Start with the actual response headers from the flow you are reviewing. Framework settings, deployment notes, and developer assumptions often differ from the Set-Cookie lines the browser receives.

Enter the site origin or a review label in Site URL or label. A real HTTP origin can trigger transport-related warnings; a plain label is treated as an HTTPS production sample.
Choose Expected cookie use based on the flow being checked: a normal first-party session, an SSO or payment return, an embedded widget, or a high-risk first-party action.
Paste one Set-Cookie header per line, paste a response header block, drag in a text file, or load one of the samples. The parser keeps multiple Set-Cookie headers separate and ignores obvious response status lines.
Use Normalize when copied headers contain extra lines or spacing. Review any parsing notes before treating the severity table as final.
Open Advanced when the review should flag missing HttpOnly on session-like cookies, broad Domain scope, or omitted Path attributes.
Read Policy Findings first, then confirm the parsed attributes in Cookie Inventory and the request-context behavior in Delivery Matrix.
Use Cookie Attribute Coverage, table exports, or JSON when you need evidence for a ticket, change review, or before-and-after remediation record.

Interpreting Results:

The highest-severity finding should drive the first fix. A strong average score does not cancel a critical row, and a low score may come from one severe cookie rather than a generally weak policy. Compare each recommendation with the cookie's real purpose before changing attributes across an entire application.

Critical usually means browser delivery is likely broken or rejected, such as SameSite=None without Secure or malformed cookie syntax.
High usually means the selected flow is not supported or the cookie carries sensitive state with a risky hardening gap, such as a session-like cookie without HttpOnly when that check is enabled.
Medium and Low rows often point to cleanup work: missing explicit SameSite, broader-than-needed cross-site delivery, Domain scope, omitted Path, duplicate attributes, or review notes that make future audits harder.
Cookie Inventory is the sanity check. If a cookie's SameSite, Secure, HttpOnly, Domain, Path, Partitioned, or lifetime information looks wrong there, fix the pasted input before using the result.
Delivery Matrix explains likely browser behavior for same-site requests, cross-site top-level safe navigations, unsafe cross-site requests, and embedded requests. Use it to diagnose why a cookie works in one browser journey but disappears in another.
Cookie Attribute Coverage is a comparison aid. It helps track remediation progress, but it is not a promise that CSRF, XSS, authorization, or third-party cookie compatibility has been solved.

Technical Details:

SameSite works on request context. The browser decides whether a cookie is same-site by comparing the request's site-for-cookies with the cookie's site, then applies Strict, Lax, None, or default behavior. That decision happens alongside other cookie rules such as Secure transport, Domain matching, Path matching, expiration, prefix restrictions, and third-party cookie controls.

Cookie scope is separate from SameSite. A host-only cookie stays on the host that set it, while a Domain attribute can make the cookie available to matching subdomains. Those subdomains may be same-site, but they can still represent different applications, teams, or trust levels. Path narrows where the browser sends a cookie within a host, yet Path should not be treated as a security boundary because another path can often set or influence related state.

Rule Core

The core review compares each cookie's SameSite value with the request contexts the selected flow requires. Missing and invalid SameSite values are treated as default behavior instead of explicit intent.

SameSite delivery behavior by request context
Cookie state	Same-site request	Top-level safe cross-site request	Unsafe or embedded cross-site request	Practical meaning
`SameSite=Strict`	Sent	Blocked	Blocked	Good for sensitive first-party state, but it can break external-link continuity, SSO returns, payment returns, and embedded widgets.
`SameSite=Lax`	Sent	Sent	Blocked	A common session default for normal navigation, but not enough for iframe state, cross-site fetches, or most POST callback patterns.
`SameSite=None; Secure`	Sent	Sent	Sent when browser policy permits	The deliberate cross-site setting. It should be limited to cookies that truly need cross-site delivery.
Missing or invalid SameSite	Default behavior	Usually default Lax behavior	Usually blocked, with compatibility exceptions in some recent-cookie cases	Harder to audit because the response relies on browser defaults instead of stating the intended policy.

Several checks are not SameSite checks at all, but they change whether the policy is trustworthy. Secure protects transport for HTTPS cookies and is required for SameSite=None and Partitioned. HttpOnly keeps server-only cookies away from JavaScript APIs. Prefixes such as __Secure-, __Host-, __Http-, and __Host-Http- promise specific combinations of Secure, HttpOnly, host-only scope, and Path=/ in browsers that enforce those prefixes.

Cookie policy hardening checks beyond SameSite
Signal	Why it matters	Typical fix
`SameSite=None` without `Secure`	Modern browsers require Secure when a cookie opts into cross-site delivery.	Add `Secure` and serve over HTTPS, or use Lax or Strict when cross-site delivery is unnecessary.
Session-like cookie without `HttpOnly`	Session, auth, access, or refresh material becomes readable by JavaScript, increasing exposure during XSS.	Add `HttpOnly` unless the cookie is intentionally read by client-side code.
Broad `Domain` scope	Matching subdomains can receive the cookie even when the login flow was meant for one host.	Prefer host-only cookies for session state unless every covered subdomain is trusted and controlled.
Prefix mismatch	Prefix names can cause supporting browsers to reject a cookie whose attributes do not match the prefix promise.	Match the Secure, HttpOnly, host-only, and `Path=/` requirements, or remove the prefix.
`Partitioned` without `Secure`	Partitioned cookies require Secure and are intended for partitioned third-party state.	Add `Secure` before relying on partitioned third-party cookie behavior.

Formula Core

The displayed coverage score is a severity-weighted audit score. Each parsed cookie starts at 100, loses points for findings, and the overall score is the rounded average of the per-cookie scores.

P_{i} = \min (100, \sum_{f = 1}^{n} w (f))

C_{i} = \max (0, 100 - P_{i}), S = round (\frac{\sum_{i = 1}^{k} C_{i}}{k})

Here P_i is one cookie's capped penalty, w(f) is the weight of each finding, C_i is that cookie's coverage score, k is the number of parsed cookies, and S is the displayed score. Critical, high, medium, and low findings use weights of 40, 26, 14, and 6; info and pass rows add no penalty. With three cookies scored 100, 74, and 60, the overall score is round((100 + 74 + 60) / 3) = 78.

The score is most useful after a remediation pass because the same sample can be checked again and compared. It should not replace the severity table. One SameSite=None cookie without Secure is more urgent than several low-severity cleanup notes.

Privacy and Accuracy Notes:

The checker parses pasted headers in the browser. Cookie names, values, scopes, and policy choices can still leave your machine through exports, screenshots, copied rows, saved JSON, or shared URLs that contain pasted inputs.

Redact cookie values when the value itself is not needed for the review. Attribute names and cookie names are usually enough for SameSite analysis.
Use delivered response headers from the environment being audited. Login, logout, callback, and embedded responses often set different cookies.
Do not treat a pass result as proof of complete CSRF, XSS, authorization, or third-party cookie compatibility coverage.
Check current browser behavior for business-critical embedded flows because third-party cookie blocking and partitioned storage policies continue to evolve.

Worked Examples:

A first-party session header such as Set-Cookie: __Host-session=abc; Path=/; Secure; HttpOnly; SameSite=Lax should normally produce a clean inventory row for a standard app session. The delivery matrix still shows that unsafe cross-site and embedded requests are blocked, which is expected for a session that does not need third-party use.

An identity-provider return cookie set as SameSite=Strict under an SSO or payment-return review should produce a high-severity warning because the cookie may not survive the provider return. The safer fix is often a short-lived callback cookie using SameSite=None; Secure, while keeping the main session cookie Lax or Strict.

An embedded widget cookie with SameSite=None but no Secure should be treated as a blocking problem. Add Secure, confirm HTTPS delivery, and then review whether Domain scope, Partitioned behavior, and browser third-party cookie policy match the widget's actual deployment.

FAQ:

Does SameSite replace CSRF tokens?

No. SameSite changes when the browser attaches cookies, but state-changing actions still need server-side CSRF defenses unless the application fits a narrow, carefully audited modern-browser case.

Why does SameSite=None require Secure?

SameSite=None opts into cross-site cookie delivery. Modern browsers require Secure for that setting so the cookie is sent only over secure channels.

Why can Lax break an SSO callback?

Lax supports same-site requests and top-level safe cross-site navigation. If the provider return uses POST, fetch, an iframe, or another embedded pattern, Lax cookies are usually not sent.

Why is Domain scope flagged?

A Domain attribute can make a cookie available across matching subdomains. That can be intentional for shared state, but it is risky for session cookies when every subdomain is not equally trusted.

Why do parsing notes appear?

Parsing notes usually mean the pasted text contained non-cookie header lines, folded lines, a non-URL site label, or cookie-like lines without the usual header prefix. Confirm the inventory before acting on severity.

Glossary:

Same-site request: A request whose initiating site matches the cookie's site context closely enough for SameSite delivery.
Cross-site request: A request initiated from another site, such as an identity-provider redirect, payment return, embedded frame, image, script, or fetch.
Safe method: An HTTP method such as GET that is expected not to change server state. SameSite=Lax treats top-level safe navigation differently from unsafe methods.
Host-only cookie: A cookie without a Domain attribute, limited to the host that set it.
HttpOnly: A cookie attribute that keeps the cookie out of browser JavaScript APIs and limits it to HTTP requests.
Partitioned cookie: A cookie intended for partitioned storage in third-party contexts. Current browser behavior requires Secure for the Partitioned attribute.

References:

Set-Cookie header, MDN Web Docs, last modified November 21, 2025.
Using HTTP cookies, MDN Web Docs.
SameSite cookies explained, web.dev, last updated May 7, 2019.
Cross-Site Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Series.