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

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