Episode 19 · Module 5 · Authentication & Identity

Session Management

18 May 2026 · 10:49 · Security for Legal SaaS

10:49 10:49

Sessions are the invisible security layer that holds authentication state, tracks activity, and enforces timeout policies. Alice and Dan cover session ID generation with cryptographic randomness, cookie security attributes (HttpOnly, Secure, SameSite), session lifecycle from creation through renewal to invalidation, session fixation attacks and defences, idle and absolute timeout policies, concurrent session management, hijacking defences, server-side storage with Redis, and legal SaaS-specific requirements including shared workstation awareness and matter-level session context.

Today’s Lesson

Security for Legal SaaS — Episode 19: Session Management

The Invisible Security Layer

Every interaction a user has with your legal SaaS platform happens within a session. The session is the container that holds authentication state, tracks activity, and enforces timeout policies. OWASP’s Session Management Cheat Sheet identifies it as one of the most critical security components — because a compromised session is a compromised user, no credentials required.

Key stat: Verizon’s 2024 DBIR reports that stolen session tokens are increasingly replacing stolen passwords as the primary credential type in breaches — because session tokens bypass MFA entirely. An attacker with a valid session cookie is already authenticated.

For legal SaaS handling privileged attorney-client communications, session management is not a checkbox feature — it’s the mechanism that determines who has access to what, for how long, and under what conditions that access can be revoked.

Session ID Generation — Cryptographic Randomness

The session identifier is a bearer token. Anyone who possesses it has the user’s access. Generation requirements are non-negotiable:

Requirement	Specification	Rationale
Entropy	Minimum 128 bits (16 bytes)	OWASP requires ≥128 bits to resist brute-force
Randomness source	CSPRNG only	`crypto.randomBytes()` (Node), `os.urandom()` (Python), `SecureRandom` (Java)
Format	Opaque, no embedded data	Session IDs must reveal nothing about the user or server state
Uniqueness	Globally unique across all active sessions	Collision = session hijacking

Never use: sequential integers (session_id=1, 2, 3... — trivially enumerable), timestamps or user IDs encoded in the session token, Math.random() or any non-cryptographic PRNG, or UUIDs from non-cryptographic generators (UUID v1 is time-based and predictable).

RFC 4086 (Randomness Requirements for Security) defines the entropy requirements. In practice: use your framework’s built-in session management — Express.js express-session, Django sessions, Rails ActionDispatch::Session — they all use CSPRNGs by default.

Session Storage — Cookie Security Attributes

Sessions should be transported via cookies with strict security attributes. The Cookie specification (RFC 6265bis) defines the attributes; OWASP maps them to security requirements.

Attribute	Value	Purpose
`HttpOnly`	`true`	Prevents JavaScript access — mitigates XSS session theft
`Secure`	`true`	Cookie only sent over HTTPS — prevents network interception
`SameSite`	`Strict` or `Lax`	Prevents CSRF by limiting cross-origin cookie transmission
`Path`	`/` (or narrowest applicable)	Limits which URL paths receive the cookie
`Domain`	Explicit, narrow	Never set to a parent domain that includes other services
`Max-Age` / `Expires`	Match session timeout policy	Browser discards cookie on expiry

Critical: SameSite=None (required for cross-site cookies) also requires Secure=true. If you need cross-origin session cookies (e.g., embedding your legal SaaS in a client’s iframe), you must use SameSite=None; Secure — but understand this re-opens CSRF vectors. Prefer same-origin architectures for legal SaaS. Google’s SameSite documentation explains the interaction.

Why Not localStorage?

Storage	XSS Resistant	CSRF Resistant	Sent Automatically
httpOnly Cookie	Yes (JS can’t read)	Needs SameSite	Yes (by browser)
localStorage	No (any JS can read)	Yes (not sent auto)	No (must attach manually)
sessionStorage	No (any JS can read)	Yes (not sent auto)	No (must attach manually)

For legal SaaS: httpOnly cookies. Always. OWASP explicitly recommends against localStorage for session tokens.

Session Lifecycle

Creation

On successful authentication: generate a new session ID (128+ bits, CSPRNG), store the session record server-side (user ID, creation time, IP, user agent), set the cookie with all security attributes, and log the authentication event.

Renewal (Re-keying)

Session fixation attacks exploit pre-authentication session IDs. The defence: regenerate the session ID on every privilege change.

Event	Action
Successful login	New session ID (mandatory)
Privilege escalation (e.g., entering admin panel)	New session ID
Password change	New session ID + invalidate all other sessions
Sensitive operation (e.g., document export)	Consider re-authentication

The old session ID must be immediately invalidated. CWE-384 (Session Fixation) documents the vulnerability class.

Invalidation (Logout)

A secure logout must: delete the server-side session record, clear the session cookie (set empty value + Max-Age=0), invalidate any associated refresh tokens, and log the event.

Common mistake: Only clearing the cookie client-side without deleting the server record. The session ID remains valid — an attacker who captured it earlier can still use it.

Timeout Policies

Timeout Type	Recommended Value	Purpose
Idle timeout	15–30 minutes	Invalidate if no activity (legal SaaS: lean toward 15 min)
Absolute timeout	8–12 hours	Maximum session duration regardless of activity
Renewal interval	Every 15 minutes	Rotate session ID periodically even during active use

NIST SP 800-63B requires re-authentication after 30 minutes of inactivity for AAL2 (Authenticator Assurance Level 2 — the level appropriate for legal SaaS handling privileged content). For AAL3, the idle timeout drops to 15 minutes.

Concurrent Session Policies

Policy	Use Case	Implementation
Unlimited concurrent	Low-risk apps, consumer products	Default — no special handling
Notify on new session	Medium risk — alert but don’t block	Push notification/email on new login
Limit to N sessions	Shared accounts, compliance	Track active sessions; oldest killed when N+1 created
Single session only	High security, billing/licensing	New login invalidates all previous sessions

For legal SaaS, notify + optional terminate is typically appropriate. A partner logging in from their office desktop should be alerted if someone simultaneously logs in from an unfamiliar location — but not automatically kicked out of their existing session, which might be mid-document review.

Google’s security model shows the gold standard: users can view all active sessions (device, location, last activity) and selectively terminate any of them.

Session Fixation

Attack Scenario:

1. Attacker visits your login page and receives a session cookie: session_id=abc123

2. Attacker tricks the victim into using this session ID (via a crafted URL, injected cookie, or XSS)

3. Victim authenticates — the server promotes session_id=abc123 to an authenticated session

4. Attacker uses session_id=abc123 — now authenticated as the victim

Defence: Regenerate the session ID immediately after successful authentication. The pre-auth session ID (abc123) is destroyed; a new ID is issued. The attacker’s copy of abc123 is now invalid.

OWASP Testing Guide v4.2 provides detailed testing procedures.

Session Hijacking Defences

Session hijacking occurs when an attacker obtains a valid session ID through network interception (mitigated by Secure flag + HSTS), XSS (mitigated by HttpOnly flag), malware/browser extension access, or physical access to an unlocked device.

Defence-in-Depth

Layer	Control
Transport	HTTPS everywhere + HSTS preload
Cookie attributes	HttpOnly + Secure + SameSite=Strict
Binding	Validate client IP range on each request (warn, don’t block — mobile users change IPs)
Fingerprinting	User-agent consistency check
Anomaly detection	Alert on geographic impossibility (login from Singapore, then London 10 minutes later)
Re-authentication	Require password/MFA for sensitive operations regardless of session state

The MITRE ATT&CK framework documents session hijacking techniques (T1550.004: Use Alternate Authentication Material: Web Session Cookie). Understanding attacker methodology informs defensive architecture.

Server-Side Session Storage

Store	Pros	Cons
In-memory (e.g., Node process)	Fast, simple	Lost on restart, no horizontal scaling
Redis	Fast, TTL native, pub/sub for invalidation	Additional infrastructure
PostgreSQL/MySQL	Durable, queryable, existing infra	Slower than Redis for high-frequency reads
Encrypted cookie (client-side)	No server state	Size limits, can’t revoke, sensitive data exposure risk

For legal SaaS at scale: Redis with PostgreSQL fallback. Redis handles the hot path (session lookup on every request). PostgreSQL provides durability and queryability (audit trails, session history, compliance reporting). Redis documentation on session management covers TTL-based expiry and key patterns.

Legal SaaS-Specific Requirements

1. Matter-level session context — When a lawyer switches between matters, consider whether the session should carry permissions for all matters simultaneously or require explicit context switching (principle of least privilege).

2. Shared workstation awareness — Court computers, law library terminals. Absolute timeout of 30 minutes maximum. Prompt for re-authentication on return from idle.

3. Regulatory compliance — Singapore’s Technology Risk Management Guidelines (MAS TRM) require session timeout policies, concurrent session controls, and session activity logging for regulated financial services — and legal SaaS handling financial litigation data may fall within scope.

4. Privileged operation gating — Downloading case files, exporting client data, changing security settings — require step-up authentication (re-enter password or MFA) regardless of session age.

Implementation Guidance

Recommended configuration: ID length: 32 bytes (256 bits) via crypto.randomBytes. Store: Redis with 30-minute TTL. Cookie: httpOnly=true, secure=true, sameSite='strict'. Regenerate on: login, privilege change, every 15 min. Absolute max: 8 hours. Concurrent limit: 5 sessions per user (notify on 3+). The express-session documentation covers configuration options; use connect-redis as the store adapter.

Conclusion

Session management is where authentication theory meets runtime reality. Generate session IDs with cryptographic randomness. Store them in httpOnly, Secure, SameSite cookies. Regenerate on every privilege change. Enforce idle and absolute timeouts. Support concurrent session visibility and selective termination. And gate sensitive operations behind step-up authentication regardless of session state.

For legal SaaS, the session is the trust boundary between “authenticated user” and “access to privileged communications.” Every weakness in session management is a direct path to privilege breach.

Next episode: OAuth 2.0 and OpenID Connect — delegated authentication, letting users log in with their firm’s identity provider instead of maintaining separate credentials.

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 19 — Session Management. Last episode we talked about JWTs and concluded that server-side sessions are often the better choice for user-facing legal SaaS. Today we cover how to implement them properly.

Alice: And “properly” matters because a session token is a bearer credential. Anyone who possesses it has the user’s access. No password required. No MFA challenge. If an attacker gets your session cookie, they are you — as far as the server is concerned.

Dan: That’s increasingly how breaches happen, isn’t it?

Alice: Verizon’s latest DBIR — their Data Breach Investigations Report, as we mentioned in Episode 16 — shows stolen session tokens replacing stolen passwords as the primary credential type in many attack chains. The reason is simple — session tokens bypass MFA — multi-factor authentication, as we covered in earlier episodes. You can have the strongest multi-factor authentication in the world, but once the user has authenticated and received a session cookie, that cookie is the key. Steal it, and you skip the entire authentication ceremony.

Dan: Let’s start with generation. How should session IDs be created?

Alice: Three non-negotiable requirements. First — cryptographic randomness. Use your platform’s CSPRNG — Cryptographically Secure Pseudo-Random Number Generator, the source of unpredictable random values. That’s crypto.randomBytes in Node, os.urandom in Python, SecureRandom in Java. Never Math.random, never timestamp-based, never sequential. Second — sufficient entropy. OWASP — the Open Web Application Security Project, as we mentioned in Episode 17 — requires at least 128 bits — that’s 16 bytes of random data. I’d recommend 256 bits for legal SaaS. Third — opacity. The session ID must be a meaningless blob of randomness. No encoded user IDs, no timestamps, no tenant identifiers. It reveals nothing.

Dan: Why does opacity matter?

Alice: Because if the session ID contains structured data — even encoded — an attacker can analyse the pattern. If IDs increment sequentially, they can guess other valid sessions. If they contain timestamps, they can narrow the search space. If they contain user IDs, they leak information about your user base. A truly random opaque string gives an attacker nothing to work with except brute force against a 128-bit or 256-bit space — which is computationally infeasible.

Dan: Once you have a session ID, how do you transport it?

Alice: Cookies, with every security attribute enabled. HttpOnly — which prevents JavaScript from accessing the cookie. This means even if you have an XSS vulnerability, the attacker’s injected script cannot read the session token. Secure — the cookie is only sent over HTTPS, never plaintext HTTP. SameSite set to Strict — the cookie is not sent on cross-origin requests, which prevents CSRF attacks. And an appropriate expiry that matches your timeout policy.

Dan: I’ve seen people store tokens in localStorage instead. What’s wrong with that?

Alice: localStorage is accessible to any JavaScript running on the page. A single XSS vulnerability — one unescaped user input rendered in the DOM — and an attacker can exfiltrate every token in localStorage with one line of JavaScript. HttpOnly cookies are invisible to JavaScript entirely. The browser manages them. Even if your page is fully compromised with XSS, the attacker cannot read the session cookie. They’d have to trick the browser into sending requests on their behalf — which SameSite prevents.

Dan: Now — session lifecycle. What happens after creation?

Alice: The critical event is session renewal — also called re-keying. Every time a user’s privilege level changes, you must generate a new session ID and destroy the old one. The most important moment is authentication. Before login, the user might have a pre-authentication session — for shopping carts, preferences, whatever. After login, that session now carries authenticated privilege. If you don’t regenerate the ID, you’re vulnerable to session fixation.

Dan: Walk me through that attack.

Alice: Session fixation. Step one — the attacker visits your login page and receives a session cookie. Let’s call it session ABC. Step two — the attacker tricks the victim into using this same session ID. Maybe through a crafted URL with the session parameter, or by injecting the cookie via XSS on a related domain. Step three — the victim authenticates. The server promotes session ABC from anonymous to authenticated. Step four — the attacker uses session ABC. They’re now authenticated as the victim. The fix is trivial — regenerate the session ID on login. Session ABC dies. A new session XYZ is created. The attacker’s copy of ABC is worthless.

Dan: What about timeouts? What’s appropriate for legal SaaS?

Alice: Two types of timeout. Idle timeout — if there’s no activity for a specified period, the session expires. NIST — the U.S. National Institute of Standards and Technology, which we referenced in Episode 17 — their 800-63B publication requires 30 minutes for AAL2 — Authenticator Assurance Level 2, the assurance level appropriate to legal SaaS — I’d lean toward 15 minutes for matters involving litigation strategy or privileged communications. Absolute timeout — the maximum session duration regardless of activity. Eight to twelve hours is typical. This prevents the scenario where a session stays alive indefinitely because the user leaves a tab open with periodic JavaScript activity.

Dan: And you mentioned renewal intervals earlier — rotating the session ID even during active use?

Alice: Every 15 minutes, generate a new session ID and invalidate the old one. The user doesn’t notice — their cookie updates silently. But if an attacker captured the old session ID, it’s now invalid. This limits the window of exploitation for any stolen session to at most 15 minutes, even if the attacker avoids triggering any other detection.

Dan: What about concurrent sessions? Should a lawyer be able to log in from multiple devices?

Alice: For legal SaaS, I recommend “notify plus optional terminate.” Allow multiple sessions — a lawyer might have their desktop at the office and their laptop at home. But notify them when a new session is created from an unrecognised device or location. Provide a dashboard showing all active sessions — device type, IP location, last activity time — and let them selectively terminate any session. Google does this well. If something looks suspicious, the user can kill it immediately.

Dan: What about session hijacking defences beyond the cookie attributes?

Alice: Defence in depth. First — HTTPS everywhere with HSTS preloaded, so the cookie can never accidentally travel over plaintext. Second — validate client characteristics on each request. Not hard-block on IP change — mobile users move between networks. But flag geographic impossibilities. If a session was active in Singapore and suddenly appears in London ten minutes later, that’s suspicious. Third — re-authentication for sensitive operations. Downloading case files, exporting client data, changing security settings — require the user to enter their password or complete MFA again, regardless of how fresh the session is.

Dan: That’s step-up authentication.

Alice: Exactly. The session proves you’re still the person who logged in this morning. The step-up authentication proves you’re still the person right now, at the moment you’re doing something that could cause irreversible harm if the session is compromised.

Dan: Server-side storage — what’s the recommended approach?

Alice: Redis for the hot path — session lookup happens on every single request, so it needs to be fast. Redis — the fast in-memory data store we mentioned in Episode 14 — gives you sub-millisecond reads and native TTL expiry — TTL being Time To Live, the countdown until a record automatically expires — sessions automatically disappear when they time out, no cleanup jobs needed. PostgreSQL as a durable fallback — for audit trails, session history, compliance reporting. You can query “show me all sessions for this user in the last 30 days” or “which sessions were active when this document was accessed.” For legal SaaS, that queryability is essential for incident response.

Dan: Any legal SaaS-specific considerations we haven’t covered?

Alice: Shared workstations. Lawyers use court computers, library terminals, shared office stations. Absolute timeout of 30 minutes maximum for these environments — and ideally detect them via device fingerprinting or require users to self-identify as using a shared device. Also — matter-level session context. When a lawyer switches between matters, consider whether their session should carry permissions for all matters simultaneously or require explicit matter selection. Principle of least privilege says: only load permissions for the matter currently being accessed.

Dan: Next episode — OAuth 2.0 and OpenID Connect. Delegated authentication — letting users log in with their firm’s identity provider instead of maintaining separate credentials.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.