SameSite=None Requires Secure: Cookie Fix Playbook
Resolve cross-site login/session failures caused by cookie attribute mismatch in modern browsers.
Cross-site subresource or fetch requests commonly need SameSite=None; modern browsers require Secure with that setting. It is still subject to browser third-party-cookie policy, scope and request credentials. These attributes alone do not guarantee acceptance.
Tools in this guide
Symptoms
- Cross-site login appears successful but session is missing on next request.
- Browser DevTools shows Set-Cookie dropped or blocked.
- Issue appears only in HTTPS/browser path, not local mock calls.
Root Cause
- SameSite=None is sent without Secure.
- Cookie domain/path or expiry policy conflicts with runtime origin.
- CORS and cookie policy are configured independently and drift apart.
Fix Steps
- Parse Set-Cookie string and verify SameSite, Secure, HttpOnly, Domain, Path attributes.
- If SameSite=None is required, enforce Secure and HTTPS consistently across environment.
- Inspect the browser’s actual cookie exclusion reasons and the next request’s Cookie header; also review CORS credentials and third-party-cookie restrictions.
Cross-site cookie baseline
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=NoneFAQ
Can SameSite=None work without HTTPS?
SameSite=None requires Secure in modern browsers. Production should use HTTPS; some browsers give localhost a secure-context exception, so local behavior is not a production compatibility test.
Is SameSite=Lax enough for SPA auth?
SameSite concerns sites, not origins or the SPA label. Lax can accompany qualifying top-level cross-site navigations, but normally not cross-site fetch/subresource requests. Review the actual flow; None + Secure can still be blocked by third-party-cookie settings.