SameSite Cookie Simulator

Diagnose “session breaks after SameSite changes” by testing same-site/cross-site context, navigation type, and method rules.

 

Status

Runs in your browser. No input is sent to a server. Useful for first-pass SameSite diagnostics.

How to use

Enter top-level URL and request URL, set SameSite/context/method/Secure to your real conditions, and click Simulate to inspect send decision and reasons.

Notes (this tool)

  • Public-suffix handling is approximated. Validate strict behavior in real browsers.
  • Browser tracking prevention (third-party cookie restrictions) is out of scope.

About this page

What does this tool do?

Given request URL, top-level URL, SameSite value, and Secure flag, it predicts whether the cookie is sent.

It explicitly checks Lax top-level navigation rules and the Secure requirement for SameSite=None.

Typical use cases

  • Session cookie is missing after OAuth/OIDC return flow
  • Login fails only in embedded iframes or cross-site transitions
  • Pre-check impact scope before SameSite policy changes

Key policy points

  • Strict: sent only in same-site contexts
  • Lax: same-site plus limited top-level navigation cases
  • None: cross-site allowed, but Secure is required

What this tool does

  • Determine same-site vs cross-site (schemeful)
  • Simulate send decision from SameSite + Secure constraints
  • Explain NG reasons (method, context, or attribute mismatch)

Debugging workflow (recommended)

  • Input URL pair for failing case (top-level and request)
  • Set SameSite, Secure, and context to the real request conditions
  • Combine with Set-Cookie Inspect / Cookie Domain-Path Matcher for root-cause confirmation

Operational notes

  • Public-suffix handling is approximated. For strict decisions, validate with real browser behavior.
  • Browser tracking prevention (third-party cookie restrictions) can further affect behavior.

Referenced specs

  • RFC 6265 (HTTP Cookies)
  • MDN: SameSite

FAQ

What happens if SameSite is not specified?

Modern browsers often treat it as Lax by default. Explicit configuration is recommended.

Is SameSite=None alone sufficient?

No. Secure is required, and browser third-party restrictions still apply.

References

  1. RFC 6265 (HTTP Cookies)
  2. MDN: SameSite

These links are generated from site_map rules in recommended diagnostic order.

  1. Set-Cookie Inspect — Parse Set-Cookie attributes and review delivery policy
  2. Cookie Domain/Path Matcher — Evaluate cookie send conditions by Domain/Path/Secure
  3. Set-Cookie Conflict Checker — Detect same-name cookie conflicts and overwrite risks
  4. Cookie Security Audit — Audit Secure/HttpOnly/SameSite settings
  5. How to Diagnose Lost Login After OAuth Return — Isolate cookie-delivery failures after IdP return across SameSite, Secure, Path/Domain, and collisions
  6. How to Diagnose Set-Cookie Not Persisting — Isolate cookie persistence failures by checking Domain/Path/Secure/SameSite in order
  7. Cookie Incident Operational Checklist — Standardize response from triage to permanent fixes across storage failures, OAuth return issues, and same-name collisions
  8. How to choose cookie tools — Route Set-Cookie, Domain-Path, SameSite, conflict, and size checks by symptom

Response Header Diagnostics

Step through raw headers to inspect Retry-After, Server-Timing, Link, and Content-Type

Example

Top-level: https://app.example.com
Request: https://api.example.com/session
SameSite=Lax, context=subresource