Browsers changed the default for cookies with no SameSite attribute from 'send everywhere' to Lax, and began rejecting `SameSite=None` without `Secure`. What broke as a result, and how do you handle it?

## What changed Historically a cookie with no `SameSite` attribute was sent on every request to its host, cross-site or not. That default made CSRF the web's default condition. Browsers changed it: an absent `SameSite` is now treated as `Lax`, and `SameSite=None` — the explicit opt-in to cross-site delivery — is only honoured when the cookie is also `Secure`, so third-party cookies must be HTTPS. Both changes are silent from the server's point of view. Nothing errors; the cookie just is not in the `Cookie` header. Symptoms are always some flavour of "the user appears logged out" or "state mismatch" in exactly one flow. ## The breakages, and why each happens **SSO callbacks using `response_mode=form_post` (SAML assertions, some OIDC configurations).** You set a state/nonce cookie, redirect the user to the IdP, and the IdP returns by making the browser **POST** the assertion to your callback URL. That POST is cross-site (initiated on the IdP's site, targeting yours) and its method is not safe, so a Lax-defaulted cookie is withheld. Your callback cannot find the state it stored and rejects the login. Fix: mark the transient state cookie `SameSite=None; Secure`, or switch the response mode to a redirect-based GET (`response_mode=query` / `fragment`), which Lax permits as a top-level safe-method navigation. **Payment provider returns.** Same shape — the PSP posts the result to your return URL and the session cookie is missing, so the confirmation page shows as anonymous. Same two fixes, plus a server-to-server webhook as the authoritative record so the UX path is not load-bearing for correctness. **Embedded iframes and widgets.** Your app rendered inside a partner's page is a cross-site subresource context; Lax withholds the cookie on *every* request in that frame, not just POSTs. Requires `None; Secure` — and increasingly `Partitioned` too, because browsers that block third-party cookies ignore `None` entirely. **Cross-site `fetch`/XHR with credentials.** A front end on `app-one.com` calling `api.app-two.com` with `credentials: 'include'` sends nothing under Lax. Either move the API under the same registrable domain (making it same-site), or use `None; Secure` plus proper CORS with `Access-Control-Allow-Credentials` and an explicit origin allowlist. **A subtle one — the transitional "Lax + POST" grace window.** Some browser versions temporarily allowed a *freshly set* cookie (roughly the first two minutes) on cross-site POSTs. Flows that appeared to work in testing failed in production for slower users and then failed everywhere when the window was removed. Never diagnose from a fast local run. ## Handling it 1. **Set `SameSite` explicitly on every cookie.** Relying on the default means your behaviour is defined by the user's browser version. Make the framework's cookie helper require the value. 2. **Classify cookies.** Most are `Lax`. A small set genuinely needs `None; Secure` — enumerate them and justify each, because each one is a cookie any site can cause to be sent, so its endpoints need CSRF tokens or origin checks independently. 3. **Prefer redesign over `None` where you can.** Redirect-GET response modes, same-registrable-domain API hosts, and server-to-server callbacks all remove the need for cross-site cookies. This also survives third-party cookie deprecation, which `None` does not. 4. **Guarantee HTTPS end to end.** `None` without `Secure` is dropped, so any lingering HTTP leg in a redirect chain kills the cookie. 5. **Test cross-site for real.** A test that drives everything on one origin never exercises this. Use a second registrable domain in integration tests (or a hosts-file alias) so cross-site POST callbacks and iframe embeds are actually covered, and assert on the presence of the cookie in the request, not just on the final page rendering. 6. **Instrument the failure.** Log "state cookie missing at callback" as a distinct metric rather than a generic auth failure; that is the signal that tells you a SameSite issue rather than an IdP problem.