Cookies / sessions · Check
SameSite=None without Secure — fixing the cross-site cookie configuration
`SameSite=None` allows a cookie to be sent on cross-site requests, which is sometimes necessary for embedded contexts, federated SSO, or third-party widgets — but it requires the `Secure` attribute, otherwise modern browsers reject the cookie outright. Without both, you get the worst of both worlds: broader CSRF surface and the cookie may not actually persist.
Why it matters
If your flow doesn't actually need cross-site delivery, `SameSite=Lax` is the safer default and removes the need for the SameSite/Secure pair entirely. Reserve `SameSite=None; Secure` for cookies that genuinely need to ride along with cross-origin embeds.
Real-world risk
SameSite=None requires Secure; misconfiguration can widen CSRF or cross-site delivery in subtle ways.
Fix steps (in order)
- If you need cross-site cookies, use SameSite=None; Secure and tighten CSRF defenses (tokens, double-submit).
- If same-site navigation is enough, prefer SameSite=Lax or Strict.
Topic explainer
CORS explained: how cross-origin requests actually work →
A practical explainer of CORS — same-origin policy, preflight requests, the headers that matter, and the configurations that quietly break security.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (session_cookie_samesite_none) clears once the externally-observable signal is in place.