Set-Cookie was blocked because it had the Secure attribute but was not received over a secure connection

Not specified by the original author.

Set-Cookie was blocked because it had the Secure attribute but was not received over a secure connection

TL;DR

The server marked the cookie Secure but served it over plain HTTP, so the browser refused to set it. Serve the login flow over HTTPS (or terminate TLS before the app and forward the scheme correctly). A Secure cookie over HTTP is a contradiction the browser resolves by dropping it.

Set-Cookie was blocked because it had the Secure attribute but was not received over a secure connection.

Steps

1. Confirm the scheme: the Set-Cookie arrived over plain HTTP instead of the https scheme. Expected: The mismatch is visible.

2. Serve the app over HTTPS end to end, or terminate TLS at the proxy and forward the scheme (X-Forwarded-Proto) so the app knows. Expected: The app sees the real scheme.

3. If behind a proxy, set the framework's proxy-trust settings so it generates Secure cookies correctly. Expected: The cookie and the scheme agree.

4. Retest the login flow and confirm the cookie is set in devtools. Expected: Sessions persist.

5. Do not 'fix' this by dropping Secure; fix the transport. Expected: The cookie keeps its protection.

When to use

• Secure cookies are never set
• the app runs behind a TLS-terminating proxy
• login sessions do not persist

When not to use

• the connection is genuinely HTTPS (check for mixed-content downgrades)
• the cookie is intentionally non-Secure (then the attribute would not be there)
• a different cookie attribute is the blocker (read the full message)

Tool compatibility

• all modern browsers
• any backend

Variant phrasings

• "Set-Cookie blocked Secure not secure connection"
• "secure cookie http blocked"
• "cookie secure attribute http"

Why it happens

The Secure attribute is a promise: this cookie only travels over encrypted connections. A server that makes the promise over plain HTTP is contradicting itself, and the browser trusts the attribute over the server. Behind proxies the app often does not know the public scheme, so it promises Secure on what it thinks is HTTP.

Edge cases

• X-Forwarded-Proto must come from your proxy only; trusting client-supplied headers is a spoofing hole
• HSTS plus always-HTTPS removes the entire class of problem
• test the full login flow, not just the cookie endpoint

Provenance

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

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

Thread query: Set-Cookie was blocked because it had the Secure attribute but was not received over a secure connection

TL;DR: The server marked the cookie Secure but served it over plain HTTP, so the browser refused to set it. Serve the login flow over HTTPS (or terminate TLS before the app and forward the scheme correctly). A Secure cookie over HTTP is a contradiction the browser resolves by dropping it.

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.