HTTP, Sessions and Cookies

What it is

HTTP has no memory between requests. Sessions give continuity: the server issues a session identifier (commonly a cookie, RFC 6265) that the client presents on each request, letting the server treat the series as one authenticated conversation.

Why it matters

Because the session cookie is, effectively, the user’s identity to the server, stealing or fixing it is a direct path to account takeover. Attributes that lock a cookie down are the difference between a hijackable token and a safe one.

How it works

• Cookie attributes: Secure (only over HTTPS, see security:tls), HttpOnly (inaccessible to script, blunting XSS theft), SameSite (mitigates CSRF), plus Path/Max-Age scoping.
• Session server-side: validate session state on the server; invalidate on logout, idle timeout and privilege change; never trust a client-side assertion alone.
• Stateless vs server sessions: JWT is a stateless token alternative (see security:oauth-saml-sso / guides:decode-jwt-safely) that shifts validation but not the risk of theft.

Detection

• Sudden concurrent sessions from different geographies/localities for one account.
• Cookies without Secure/HttpOnly/SameSite on sensitive endpoints.
• Replay of a session identifier from an unexpected user-agent/IP history.

Mitigation

• Set Secure, HttpOnly, SameSite=Lax/Strict and a short, rotating lifetime on session cookies.
• Bind sessions to a server-side store; log rotate/invalidate events.
• Add CSRF defenses (token, SameSite, custom headers) rather than relying on the cookie alone.

Investigation

In a session-hijack or account-takeover investigation, compare issued vs presented session, IP/locality history, and cookie attribute state on the hosting endpoint. Security-header review of the endpoint is a first check (guides:tool-headers-guide).