Cookies let a web application keep state across otherwise independent HTTP requests. A server sends a small text value in a Set-Cookie response header; the browser stores it and returns it in a Cookie header on later requests to the applicable domain. Cookies commonly carry a session identifier, allowing the application to recognize a logged-in user until the cookie expires or is cleared. section 2.11
That convenience makes session cookies valuable targets. Browser domain separation prevents a cookie set for one domain from being sent to an unrelated malicious domain, but subdomains require deliberate decisions about which hosts should be able to read a cookie. section 2.11
Set defensive attributes on sensitive session cookies:
- Use Secure so the browser sends the cookie only over HTTPS, avoiding exposure on an intercepted HTTP request. section 2.12
- Use HttpOnly so JavaScript cannot read the cookie, reducing theft after injected script executes. section 2.13
- Use SameSite=Strict to withhold cookies from cross-site requests, or SameSite=Lax when cross-site GET navigation must remain usable. section 2.14
- Set Expires or Max-Age for sensitive sessions; avoid leaving their lifetime dependent on browser behavior. section 2.15
A practical session-cookie policy
A session cookie can combine Secure, HttpOnly, SameSite=Lax, and Max-Age. Secure protects transport, HttpOnly limits script access, Lax withholds cookies from cross-site POST, PUT, and DELETE requests, and Max-Age limits how long a stolen or unattended session remains useful. On logout, send the same cookie with an empty value and Max-Age=-1 so the browser discards it. section 2.14 section 2.15 section 2.16
HTTP/2.0 200 OK Content-Type: text/html Set-Cookie: session_id=9264be3c7df1250; Secure; HttpOnly; SameSite=Lax #1
This Set-Cookie header shows a session identifier protected with Secure, HttpOnly, and SameSite=Lax. section 2.14
