HTTP is a stateless protocol. Each request is independent, with no built-in memory of previous interactions. Cookies solve this by storing small pieces of data in the browser that are automatically sent with every subsequent request to the same domain. This is how websites remember that you are logged in, what is in your shopping cart, or what language you prefer.
When you log in to a web application, the server creates a session and assigns it a unique session ID. This ID is stored in a cookie and sent with every request. The server uses the session ID to look up your identity and permissions. The actual session data (who you are, when you logged in, your roles) lives on the server; the cookie just holds the key.
The security of this entire mechanism depends on keeping the session ID secret. If an attacker obtains your session ID, they can impersonate you without needing your username or password.
Several cookie attributes significantly impact security:
Secure ensures the cookie is only sent over HTTPS connections. Without this flag, the cookie can be intercepted on unencrypted HTTP connections, such as on public Wi-Fi.
HttpOnly prevents JavaScript from accessing the cookie via document.cookie. This is critical for defending against XSS attacks that try to steal session cookies. If an attacker injects a script that reads document.cookie, HttpOnly cookies will not be included.
SameSite controls whether the cookie is sent with cross-origin requests. SameSite=Strict means the cookie is never sent on cross-site requests. SameSite=Lax (the default in modern browsers) sends the cookie only on top-level navigations, not on embedded requests. SameSite=None sends the cookie on all requests but requires the Secure flag.
Domain specifies which domains receive the cookie. Set it as narrowly as possible. A cookie set for .example.com will be sent to all subdomains, which increases exposure.
Path restricts the cookie to specific URL paths on the domain.
Max-Age / Expires controls cookie lifetime. Session cookies (no expiration set) are deleted when the browser closes. Persistent cookies survive browser restarts. For session IDs, shorter lifetimes reduce the window for session hijacking.
Session hijacking occurs when an attacker steals a valid session ID and uses it to impersonate the user. Prevention includes using Secure and HttpOnly flags, implementing HTTPS everywhere, and regenerating session IDs after login.
Session fixation is an attack where the adversary sets a known session ID in the victim's browser before they log in. When the victim authenticates, the attacker already knows the session ID. Defense: always generate a new session ID upon successful authentication.
Cross-Site Request Forgery (CSRF) tricks a user's browser into making unintended requests to a site where they are authenticated. The browser automatically includes cookies, so the request appears legitimate. Defense: use anti-CSRF tokens and the SameSite cookie attribute.
Always set Secure, HttpOnly, and SameSite on session cookies. Generate session IDs using a cryptographically secure random number generator with at least 128 bits of entropy. Implement session timeouts (both idle and absolute). Invalidate sessions on the server side when users log out, rather than just deleting the cookie. Regenerate the session ID after any privilege change, especially after login.
Monitor for anomalies like a single session ID appearing from multiple IP addresses or user agents, which may indicate session theft.