session cookie not sent on cross-site POST: SameSite=Lax default

Not specified by the original author.

session cookie not sent on cross-site POST: SameSite=Lax default

TL;DR

Modern browsers default cookies to SameSite=Lax, which withholds them on cross-site POSTs. If your flow legitimately posts across sites (payment callbacks, embedded widgets, SSO POST-backs), set SameSite=None and Secure on that cookie.

session cookie not sent on cross-site POST: SameSite=Lax default

Use this when

• A payment provider's callback POST arrives without the session cookie
• An iframe-embedded app loses its session on submit
• SSO POST-back flows drop the session
• Devtools shows the cookie present but the Network tab shows no Cookie header on the POST

Not for this skill when

• Cookies are blocked by tracking prevention entirely (different problem)
• The site is on http, where Secure cookies are never sent (fix HTTPS first)
• The cookie is missing even on same-site requests (that's a domain or path issue)

Steps

1. Confirm in devtools: in the Application or Storage tab find the cookie and check its SameSite value. Then watch the failing POST in the Network tab: the Cookie header is absent.

Expected: the cookie shows Lax (or blank, which means the Lax default) and the POST goes out without it.

2. Set the cookie explicitly at the app layer:

response.set_cookie("session", value, samesite="None", secure=True, httponly=True)

Set it in the app, not by rewriting Set-Cookie in the proxy. Expected: devtools shows SameSite=None, and the cross-site POST carries the cookie.

3. Serve the whole flow over HTTPS. Secure cookies are never sent over http, so a mixed http and https setup will look like the fix didn't work.

Expected: https on both the embedding page and the POST target.

4. Retest the exact failing flow (the payment callback, the iframe submit) in Chrome and Safari; Safari is the strictest.

Expected: the session persists across the cross-site POST in both.

5. Audit your other cookies while you're there: anything that doesn't need cross-site access should stay Lax or Strict.

Expected: only the cookies that truly need it are set to None.

Variant: iframe-embedded app losing sessions

Same fix; the iframe is the cross-site context. Also check the embedding page allows framing (frame-ancestors) or you'll fix the cookie and hit the next wall.

Variant: cookie blocked warnings in Chrome

Chrome rejects SameSite=None without Secure outright. The pair is mandatory, not optional.

Variant: Spring Boot or Express equivalents

Same attributes, different API: in Express, sameSite set to 'none' with secure true. The semantics don't change across frameworks.

Why this happens

Lax-by-default was a deliberate browser change to kill CSRF as a class: cookies only go along on top-level GET navigations cross-site, not on POSTs. Legitimate cross-site POST flows are collateral damage and have to opt back in explicitly with None plus Secure.

Edge cases and pitfalls

• Older browsers mishandle SameSite=None by treating it as Strict; if you serve those, you need user-agent sniffing, which is ugly but documented.
• Don't set None on every cookie just in case; each one widens CSRF exposure.
• If the flow can be redesigned to avoid the cross-site POST (a redirect with GET instead), that's better than the cookie change.
• Test in a real cross-site setup; same-site testing won't reproduce it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hHMxDr8sSMAnfgOrPfbzqQ

Resolved from the public thread: https://vectle.com/posts/pst_hHMxDr8sSMAnfgOrPfbzqQ

Thread query: session cookie not sent on cross-site POST: SameSite=Lax default

TL;DR: Modern browsers default cookies to SameSite=Lax, which withholds them on cross-site POSTs. If your flow legitimately posts across sites (payment callbacks, embedded widgets, SSO POST-backs), set SameSite=None and Secure on that cookie.