Session Security

Extends Auth Fundamentals@markdowners/auth-fundamentals with the specifics of keeping an established session safe for its entire lifetime, not just at login.

Set session cookies with HttpOnly (unreadable by JavaScript, blocking most XSS-based session theft), Secure (never sent over plain HTTP), and SameSite=Lax or Strict (blocking most CSRF vectors) — all three, always, with no exceptions for "just local dev" carried into any deployed environment.
Scope the cookie's Path and Domain as narrowly as correctness allows — a session cookie scoped to a parent domain is also sent to every subdomain, widening the attack surface unnecessarily.

Session lifetime

Set a reasonable absolute expiration (session cannot be extended forever, e.g. 30 days) and, for sensitive applications, a shorter inactivity timeout that logs the user out after a period with no activity.
Regenerate the session identifier on any privilege change (login, logout-then-login, role elevation) — reusing the same session ID across a privilege boundary enables session fixation attacks.

Support explicit "log out this session" and "log out all other sessions" — a session store that can't be queried and individually invalidated (e.g. an unmodified stateless token with no revocation list) can't support either, which is the practical argument for pairing any long-lived token with a server-side check.
Invalidate all sessions immediately on password change or detected account compromise — a stolen session should not outlive the credential rotation meant to kill it.

For any cookie-authenticated state-changing request (non-GET), require a CSRF token (double-submit cookie or synchronizer token pattern) in addition to SameSite — SameSite=Lax alone still allows top-level GET navigations to carry cookies, so state-changing actions must never be triggerable via a plain GET request.
Never accept a state-changing request based on cookie presence alone if the request could plausibly be triggered cross-site.

Track enough metadata per session (creation time, last-seen time, rough device/browser, IP at creation) to let a user meaningfully review and revoke their own active sessions from a settings page.
Treat a sudden change in a session's originating IP/geography mid-session as a signal worth logging and, for sensitive actions, worth re-authenticating — not proof of compromise on its own, but a signal.

Never store session tokens in localStorage or sessionStorage for anything security-sensitive — both are directly readable by any script running on the page, making them trivially exfiltrable via XSS in a way HttpOnly cookies are not.