HTTP headers · Response
Set-Cookie
Set-Cookie asks the client to store a cookie and defines its scope, lifetime and security attributes.
Key facts
| Type | Response |
|---|---|
| Header count | One cookie per header |
| Secure | HTTPS only |
| HttpOnly | Hidden from JavaScript |
| SameSite | Lax, Strict or None |
| Lifetime | Max-Age or Expires |
| SameSite=None | Requires Secure |
| Standard | RFC 6265bis |
Attributes that control risk
Secure restricts the cookie to HTTPS. HttpOnly hides it from scripts, which reduces the impact of XSS. SameSite=Lax is a sensible default: the cookie is sent on top-level navigations but not on most cross-site subrequests. Strict is stronger and can break inbound links; None restores cross-site sending and requires Secure.
Max-Age is relative and wins over Expires when both are present. A session cookie without either disappears when the browser session ends, though browsers may restore sessions.
Domain and path
Without Domain, a cookie is host-only. Adding a domain widens it to subdomains, which is rarely necessary and increases exposure. Path is a prefix match, not a security boundary; a cookie set for / goes everywhere on the host.
Deleting a cookie means setting it again with the same name, domain and path and an expiry in the past. Mismatched attributes create a second cookie instead of removing the first.
Frequently asked questions
Why does SameSite=None require Secure?
Because a cross-site cookie without TLS can be intercepted. Browsers reject the combination.
What happens if I set the same cookie twice?
The later Set-Cookie header replaces it if name, domain and path match. Different paths create separate cookies.