# 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.

```text
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