# Session Management Security: HttpOnly Cookies, CSRF, and SameSite Explained > An advanced guide to session management security — covering HttpOnly and Secure cookie flags, CSRF attack mechanics, SameSite policy, and session fixation prevention. - **Published:** 2025-12-17 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** sessions, security, csrf, cookies, web-security - **Canonical URL:** https://clixo.sh/blog/session-management-security-httponly-cookies-csrf Session management is the part of your authentication system that runs on every single request after the user logs in. It is also where a significant number of web application compromises begin — not through broken cryptography, but through misconfigured cookies, missing CSRF protections, or sessions that never properly expire. These are not exotic vulnerabilities; they are the bread and butter of real-world web security assessments. This guide covers the full picture of production session management: what the flags do, what they do not do, and how the attacks they prevent actually work. ## How Sessions Work and Where They Break When a user authenticates, the server creates a session record and sends back a session ID in a cookie. Every subsequent request carries that cookie. The server looks up the session, finds the user's identity, and processes the request. ```mermaid stateDiagram-v2 [*] --> Unauthenticated Unauthenticated --> Pending : Submit credentials Pending --> Authenticated : Server issues new session ID Authenticated --> Authenticated : Requests carry HttpOnly cookie Authenticated --> Expired : Idle or absolute timeout Authenticated --> Unauthenticated : Logout invalidates server session Expired --> Unauthenticated : Session removed from store ``` The session ID is the crown jewel. Whoever holds it can impersonate the user. Session management security is fundamentally about protecting that identifier from theft and misuse. ## The HttpOnly Flag Setting `HttpOnly` on a cookie means the browser will not expose it to JavaScript — not via `document.cookie`, not via `XMLHttpRequest` headers that JavaScript can read, not via any browser API. The attack this prevents: **cross-site scripting (XSS) based session theft**. If an attacker injects JavaScript into your page — via a stored XSS vulnerability, a malicious ad, or a compromised third-party script — and your session cookie is not `HttpOnly`, the injected code can read `document.cookie` and exfiltrate the session ID to an attacker-controlled server. `HttpOnly` does not prevent XSS. It prevents XSS from escalating into session theft. The session cookie is still sent on every request — the browser handles that, not JavaScript. The distinction matters: `HttpOnly` is not a substitute for fixing XSS vulnerabilities. Set it unconditionally on session cookies: ``` Set-Cookie: session_id=...; HttpOnly; Secure; SameSite=Lax ``` ## The Secure Flag `Secure` tells the browser to only send the cookie over HTTPS connections. Without it, if a user connects over HTTP — even accidentally, via a redirect, or on a network that strips HTTPS — the session cookie is transmitted in plaintext. A passive network attacker on the same WiFi network can capture unencrypted traffic. If session cookies travel over HTTP, the attacker captures them. `Secure` should be set on all cookies in production. The only context where it is legitimately absent is local development over HTTP, and even there it is worth running HTTPS locally to catch issues early. ## SameSite and CSRF Protection `SameSite` is the modern defense against cross-site request forgery. To understand why, you need to understand CSRF. **The CSRF attack:** A user is logged into your application. They visit a malicious website. The malicious site makes a request to your application — a form submission, an API call — from within the user's browser. The browser, following normal rules, sends the user's session cookie with the request. Your server sees a valid session and processes the request as if the user intended it. CSRF works because browsers historically sent cookies on any request to a given domain, regardless of where the request originated. The attacker exploits that behavior. `SameSite` changes the rule: - **`SameSite=Strict`**: The cookie is never sent on cross-site requests. Maximum protection, but breaks some legitimate cross-site flows — following a link from an email to a page that requires the session, for example. - **`SameSite=Lax`**: The cookie is sent on top-level navigation (clicking a link) but not on cross-origin sub-requests like embedded images or forms. This is the right default for most applications. - **`SameSite=None`**: The cookie is sent on all cross-site requests. Requires `Secure`. Use only when your legitimate use case requires cross-site cookie sharing (embedded widgets, SSO where the IdP and SP are on different domains). `SameSite=Lax` blocks the most common CSRF attack vectors while preserving normal user flows. It is the correct default. ### When `SameSite` is Not Enough `SameSite=Lax` does not cover all CSRF scenarios. Specifically: - **Same-site requests from subdomain attacks.** If an attacker can inject content on `attacker.yourdomain.com`, that request is same-site and the cookie is sent. - **Old browsers.** Some older browsers do not support `SameSite`. For applications that must support them, layer a traditional CSRF token on top. - **Mobile app webviews.** Cookie SameSite behavior in webviews is not always predictable. For applications with significant security requirements, layer both: `SameSite=Lax` as the primary defense, plus a CSRF token (`Double Submit Cookie` pattern or `Synchronizer Token` pattern) as a secondary defense. ## Session Fixation Session fixation is less commonly known but worth understanding. In a fixation attack, the attacker sets a known session ID on the victim's browser before the victim logs in — via URL parameter injection, a subdomain cookie set trick, or a misconfigured login endpoint that accepts externally provided session IDs. When the victim logs in, the server associates the attacker's known session ID with the authenticated user. The attacker, who already knows the session ID, now has an authenticated session. **Prevention:** Issue a fresh session ID immediately upon successful authentication. This is sometimes called session regeneration. The old (unauthenticated) session is invalidated, and the new session ID has no value to an attacker who set up the fixation. Most mature session frameworks do this automatically. If you are using a custom session implementation, add this explicitly. ## Session Timeout Sessions that never expire are persistent risk. A session token captured from a user's device years ago should not still grant access today. Two types of timeout are needed: - **Idle timeout.** Invalidate the session after a period of inactivity (30-60 minutes for most apps, shorter for sensitive operations). - **Absolute timeout.** Invalidate the session after a maximum lifetime regardless of activity (8-24 hours for most apps). Forces re-authentication periodically. Implement both. Idle timeout alone can be defeated by an attacker who makes periodic requests to keep the session alive. ## Logout Must Invalidate Server-Side State This is straightforward but commonly skipped: when a user logs out, the server must delete or invalidate the session. Clearing the cookie on the client alone is not sufficient — any attacker who captured the session ID before logout can still use it. On logout: 1. Delete the session from your session store (Redis, database). 2. Send `Set-Cookie: session_id=; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure` to clear the cookie in the browser. 3. Respond with a redirect to the login page. Session management security is largely unglamorous — it is cookie flags and timeouts and a correct logout flow. But getting these fundamentals wrong creates the attack surface that leads to account compromise. Every one of these controls is worth the five minutes of configuration it takes to enable. If you need a security-first session management implementation built into your web application from the ground up, [Clixo builds production authentication systems](https://clixo.sh/#contact) for teams who take it seriously. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)