SameSite=None must be Secure: cookie rejected by browser

Not specified by the original author.

SameSite=None must be Secure: cookie rejected by browser

TL;DR

The cookie sets SameSite=None but lacks Secure, so the browser rejects it outright. Add Secure (and serve over HTTPS). SameSite=None without Secure is invalid by spec, and browsers enforce it.

Cookie 'x' was rejected because SameSite=None requires the Secure attribute.

Steps

1. Find the Set-Cookie: it has SameSite=None without Secure. Expected: The invalid combination is visible.

2. Add Secure to the cookie and ensure the response goes over HTTPS. Expected: The pair is valid.

3. Retest the cross-site flow that needs the cookie. Expected: The cookie is set and sent.

4. Audit other cookies for the same invalid combination. Expected: All are fixed.

5. Consider whether SameSite=None is even needed; Lax covers most same-site-plus-top-level flows. Expected: The minimal attribute set is used.

When to use

• cookies with SameSite=None are rejected
• a cross-site flow needs cookies
• the console names the SameSite/Secure rule

When not to use

• the cookie is first-party (SameSite=Lax is probably right)
• the site is HTTP-only (SameSite=None cannot work there at all)
• the rejection names a different rule (read the message)

Tool compatibility

• all modern browsers
• cross-site cookie flows

Variant phrasings

• "SameSite=None must be Secure"
• "cookie rejected samesite none secure"
• "samesite none without secure"

Why it happens

SameSite=None opts a cookie into cross-site sending, which is the riskiest mode, so the spec requires Secure alongside it: cross-site cookies must at least be encrypted in transit. Browsers reject the invalid combination rather than downgrade it, because silent downgrades are how cookie security erodes.

Edge cases

• older browsers treat unknown SameSite values oddly; test the actual user base
• SameSite=None with Secure over plain HTTP still fails; the transport must be HTTPS
• default is now Lax in modern browsers; explicit None is only for real cross-site needs

Provenance

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

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

Thread query: SameSite=None must be Secure: cookie rejected by browser

TL;DR: The cookie sets SameSite=None but lacks Secure, so the browser rejects it outright. Add Secure (and serve over HTTPS). SameSite=None without Secure is invalid by spec, and browsers enforce it.

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.

Not specified by the original author.

TL;DR

SameSite controls when the browser attaches a cookie to cross-site requests: Lax (the modern default) sends it on top-level navigations but not on cross-site subrequests, which kills most CSRF; Strict never sends it cross-site, which is safest but logs users out when they arrive from external links; None allows cross-site sending but requires the Secure flag and HTTPS. For login/session cookies, Lax is the right default; reach for Strict only where the UX cost is acceptable.

how to set SameSite cookies correctly

Use this when

• You are setting a session, auth, or CSRF cookie and need to pick a SameSite value
• A CSRF review asks what protects your cookie-based endpoints
• An embedded widget, iframe, or cross-site API flow stopped receiving cookies
• You are debugging 'cookie not sent' after a browser update

Not for

• GDPR cookie-consent banners (legal question, not this attribute)
• Deciding between cookies and bearer tokens overall
• Same-origin cookie flags like HttpOnly (related but separate)

Steps

1. Default to Lax for session cookies. Set it explicitly rather than relying on browser defaults: Set-Cookie: session=[id]; Path=/; HttpOnly; Secure; SameSite=Lax. Lax blocks the dangerous case (a malicious site triggering a state-changing POST with your cookie) while letting normal link clicks into your site keep the user logged in. Expected output: the Set-Cookie response header shows SameSite=Lax, and cross-site POSTs from a test page arrive without the cookie.

2. Use Strict where the UX tradeoff is worth it. Banking, admin panels, and settings pages benefit from Strict because the cookie never leaves your site context. Warn users (or handle gracefully) that arriving via an external link starts logged out until they navigate inside the site. Expected output: clicking a link from email to the admin panel shows a logged-out state until the user clicks any in-site link.

3. Use None only for genuinely cross-site needs, and always with Secure. Embedded checkouts, widgets, or SSO flows that must work inside third-party iframes need SameSite=None; Secure (HTTPS only). Browsers reject SameSite=None without Secure outright. Expected output: the iframe flow receives its cookies, and the Set-Cookie header shows both SameSite=None and Secure.

4. Keep HttpOnly and Secure alongside SameSite. SameSite stops cross-site sending; HttpOnly stops JavaScript from reading the cookie (XSS defense); Secure stops it leaking over plain HTTP. They are three independent layers, and session cookies normally want all three. Expected output: document.cookie in devtools does not reveal the session cookie, and it is never sent over http.

5. Test the matrix in a real browser. Build a tiny test page on a different origin that issues GET, top-level navigation, and POST requests to your app, and watch which requests carry the cookie in devtools. Also test your OAuth/OIDC callback flow, which is a cross-site POST in some providers and breaks under Strict. Expected output: a table of request types vs cookie presence that matches your intent, with the OAuth callback verified working.

6. Watch for the Lax-by-default gotcha on older setups. If you never set SameSite, modern browsers treat it as Lax, which can silently break old cross-site integrations that assumed cookies always flow. Set the attribute explicitly everywhere so behavior is intentional. Expected output: no cookie in your app relies on an unset SameSite attribute.

Variant phrasings

• "SameSite Lax Strict None explained"
• "Set-Cookie SameSite example"
• "why is my cookie not sent in iframe"
• "SameSite None Secure not working"

Edge cases and pitfalls

• Some OAuth providers POST the callback cross-site; Strict on the session cookie can break login, so test the full login round-trip after changing it.
• iOS Safari versions have had quirky SameSite=None handling; if you must support older Safari in iframes, test there specifically.
• SameSite is a mitigation, not a full CSRF fix: keep anti-CSRF tokens on state-changing endpoints too.

Provenance

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

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

Thread query: how to set SameSite cookies correctly

TL;DR: SameSite controls when the browser attaches a cookie to cross-site requests: Lax (the modern default) sends it on top-level navigations but not on cross-site subrequests, which kills most CSRF; Strict never sends it cross-site, which is safest but logs users out when they arrive from external links; None allows cross-site sending but requires the Secure flag and HTTPS. For login/session cookies, Lax is the right default; reach for Strict only where the UX cost is acceptable.