What Is a Web Session?

HTTP is a stateless protocol: every request is independent. Sessions allow multiple requests to be linked to the same user. After a successful login, the server generates a random session identifier (Session ID) and sends it to the browser as a cookie. On every subsequent request, the browser sends this cookie back, and the server verifies the ID matches an active session.

The security of this mechanism relies entirely on the unpredictability and confidentiality of that identifier.

Lifecycle of a Secure Session

A properly managed session follows this cycle:

  1. Login: the user submits credentials.
  2. Creation: the server verifies credentials and generates a cryptographically random Session ID (at least 128 bits of entropy).
  3. Transmission: the cookie is sent with the HttpOnly, Secure, and SameSite=Strict attributes.
  4. Validation: every incoming request is verified server-side — the cookie alone is not enough; the ID must exist in active session storage.
  5. Logout: the session is invalidated server-side. Deleting the cookie on the client only is insufficient: an attacker who intercepted the ID could keep using it.

Session Fixation and ID Regeneration

Session fixation is an attack where the attacker forces a known Session ID onto the victim before they log in. Once the victim authenticates with that ID, the attacker can take over the session.

The fix is straightforward and mandatory: regenerate the Session ID immediately after authentication and at every privilege change (e.g., role elevation). The old ID must be invalidated.

# Python Flask example
from flask import session
session.regenerate()  # Generates a new ID, copies data from the old session

Session Hijacking: Protecting the Cookie

Session hijacking means stealing the session cookie. Three cookie attributes are essential:

  • HttpOnly: prevents JavaScript from reading the cookie, blocking XSS (Cross-Site Scripting) attacks.
  • Secure: the cookie is only transmitted over HTTPS, preventing plaintext interception on unencrypted networks.
  • SameSite=Strict: the cookie is not sent on cross-site requests, blocking CSRF (Cross-Site Request Forgery) attacks and some hijacking vectors.

Session Lifetime and Expiration

Two types of timeout work together:

  • Absolute timeout: the session expires after a fixed duration since creation, regardless of activity. Typically 8 hours for a business application.
  • Idle timeout: the session expires after X minutes of inactivity — 15 to 30 minutes is common. This is the most effective control against sessions left open on shared workstations.

Both mechanisms must be enforced server-side, not solely via the cookie's Expires attribute.

Stateful Sessions vs JWT Tokens

Stateful sessions store data in server memory or a database (Redis, SQL). The advantage: revocation is immediate — invalidating the ID is enough. The drawback: every server must share the session store, which adds horizontal complexity.

JWT (JSON Web Token) tokens are stateless: all information is encoded in the token itself, signed but not encrypted by default. Advantage: no centralized store needed. Major drawback: a JWT cannot be revoked before it expires unless you maintain a blocklist — which reintroduces state. For standard user sessions, stateful sessions are often preferable.

Audit Your Site's Session Management

Poor session configuration can expose your users to serious breaches. Run a free audit to detect session issues, misconfigured cookies, and authentication vulnerabilities on your site.