A session ID is the value that lets a web application recognize an already authenticated browser across separate HTTP requests. After login, the application creates a session record containing the user’s identity and recent activity, then sends the identifier—sometimes the session data itself—to the browser. The browser returns it on later requests, allowing the application to link those requests to the same session. section 2.11 section 9.0
HTTP/2.0 200 OK Content-Type: text/html Set-Cookie: session_id=9264be3c7df12505 #1 Set-Cookie: accepted_terms=1 #2
A response can set a session_id alongside unrelated cookie state. Treat the session ID as sensitive: possession may be enough to act as the logged-in user. section 2.11
GET /home HTTP/2.0 Host: www.example.org Cookie: session_id=9264be3c7df12505; accepted_terms=1 #1
On a later request, the browser returns the session ID in the Cookie header, which lets the server associate the request with the existing session. section 2.11
A stolen session ID can enable session hijacking: an attacker can impersonate the victim without obtaining credentials. Network attackers historically captured insecure session traffic on shared Wi-Fi; HTTPS prevents observers from reading traffic in transit. Set the Secure attribute so browsers never send the session cookie over an unencrypted connection. section 9.6 section 9.0
Protected session cookie
A session cookie can include Secure and HttpOnly. Secure restricts transmission to encrypted connections; HttpOnly prevents JavaScript running in the browser from accessing the cookie. These controls reduce different routes to session-ID theft. section 9.6 section 9.11
Harden session IDs and the mechanisms that carry them:
- Use a maintained, proven session-management framework and apply security patches. section 9.11
- Generate IDs with a strong random-number algorithm, and never accept an ID proposed by the client. section 9.11
- Disable URL-based session IDs, which can expose identifiers through URLs. section 9.11
- For client-side sessions or JWTs, use digital signatures or encryption to detect or prevent tampering; do not store data users must not read in signed-only state. section 9.11
Cookies are separated by domain, so a cookie set for one domain is not sent to another. Subdomains require deliberate decisions about which hosts, if any, should be able to read a session cookie. Restrict cookie access as much as possible because session cookies are valuable attacker targets. section 2.11
