Back to TechSplainer

    Session Cookie: The Tiny File That Proves You're Already Logged In

    TL;DR:

    A session cookie is a small file your browser stores after you log in. It tells websites "this person already authenticated -- don't ask them again."

    Think of it like a valet parking ticket. You hand your keys to the valet. They give you a ticket stub. Later, anyone who shows up with that ticket gets your car back -- no ID check, no argument. The ticket IS the proof.

    On a good day, your session cookie lives only in your browser, only works on your device, and expires after a few hours. On a bad day, somebody else has a copy of your ticket -- pulled from a phishing site or scraped by malware. The valet hands over the keys. The whole system assumed only you would have the stub.

    Beyond the Basics:

    Here's what a session cookie actually contains.

    When you successfully log in to a web application -- Microsoft 365, your bank, a CRM -- the server issues your browser a cookie. Under the hood, it's a short string of characters stored in browser memory (or on disk, depending on configuration), tagged with the originating domain, an expiration time, and a set of security flags.

    Three flags matter most:

    1. Secure. The cookie only travels over HTTPS. A network-level attacker can't grab it over plain HTTP. Every modern identity provider sets this.
    2. HttpOnly. The cookie is invisible to JavaScript running in the page. This blocks cross-site scripting (XSS) attacks from stealing it. Also standard on well-designed platforms.
    3. SameSite. Controls when the cookie gets sent on cross-site requests. Strict or Lax prevents most cross-site request forgery (CSRF) attacks. Default for modern session cookies should be Lax at minimum.

    The cookie's VALUE is typically either a random session ID (the server looks it up in a database to find the user) or a signed JSON Web Token (JWT) that contains the user's identity, permissions, and expiration, cryptographically signed by the server.

    When you click anything inside the app, the browser automatically includes the cookie in the request. The server checks it, says "valid session," and serves the page. No password typed, no MFA prompt. This is how apps feel "logged in" for hours at a time.

    Why attackers want session cookies:

    • They're portable. A cookie stolen from your browser works in the attacker's browser (mostly -- see token binding below). The attacker pastes it in, and the site treats them as you.
    • They bypass MFA. MFA happens at login. Once the cookie is issued, the MFA step is done. A stolen cookie is an already-authenticated session.
    • They're hard to invalidate automatically. Unless the identity provider has Continuous Access Evaluation configured, the cookie stays valid for its full lifetime -- often 1-24 hours for access tokens, up to 90 days for refresh tokens in Entra ID.

    Defenses that work against session cookie theft:

    • Token binding via Conditional Access. Tie the session to a specific device, IP, or compliance state. A cookie presented from somewhere else gets rejected.
    • Short lifetimes. Entra ID admins can shorten token lifetime for sensitive accounts.
    • Continuous Access Evaluation (CAE). Entra ID can revoke tokens mid-session when risk signals change.
    • Phishing-resistant MFA. FIDO2 stops the AiTM phishing that's the primary cookie-theft vector right now.

    Cookies aren't going away. They're how the web stays stateful. But treating them as a valuable credential -- because they ARE one -- changes how you design identity systems around them.

    Learn More: