How to Prevent Browser and Token Session Hijacking (With or Without MFA)

Authentication happens once. Afterward the browser or app carries proof of it for hours or days: a session cookie, an OAuth access token, a refresh token, or on Windows a Primary Refresh Token. Whoever presents that artifact is the user, as far as the server can tell.

Attackers take it three ways. Adversary-in-the-middle phishing kits proxy the real sign-in page, relay the MFA prompt, and keep the cookie that comes back. Infostealer malware reads cookies and cached tokens out of the browser profile. Cross-site scripting or a loose cookie configuration hands the session to any script that asks. None of these need the password again, so the second factor is never consulted.

The fix is to make the stolen artifact nearly worthless: hard to read, short-lived, tied to its device, and revocable the moment something looks wrong.

HttpOnly, Secure, SameSite

HttpOnly stops document.cookie from reading the session, which turns a successful XSS from "steal the session" into "annoy the user." Secure keeps the cookie off plaintext requests. SameSite=Lax is the sane default and blocks most cross-site request forgery; use Strict for admin consoles and anything that moves money.

Scope, prefixes and rotation

Use the __Host- prefix so the cookie can't be set with a Domain attribute or over plain HTTP. Issue a new session identifier at login, at logout and on any privilege change, so a session fixed before authentication is worthless after it. Keep sessions server-side with a way to kill one by ID.

Short-lived access tokens

An access token that lives for days is a stolen credential that lives for days. Keep access tokens to minutes and let the refresh token keep users signed in; the access token is what will leak, the refresh token is what you protect.

Refresh-token rotation with reuse detection

Each time a client redeems a refresh token, issue a new one and invalidate the old one. If the same refresh token ever arrives twice, one of the two holders is an attacker: revoke the whole token family and force a fresh login. Single-page and mobile apps can't keep a client secret, so for them rotation isn't optional.

Bind the token to the sender

Bearer tokens work for whoever bears them. Mutual TLS ties a token to a client certificate; DPoP (Demonstration of Proof-of-Possession) ties it to a key the client holds. A token lifted off the wire or out of storage is then rejected without the matching proof. Start with your highest-value APIs.

If your users sign in through Microsoft Entra, token binding is already available. Token Protection is a Conditional Access session control that only accepts sign-in session tokens cryptographically bound to the registered device, so a Primary Refresh Token copied off one machine fails on another. It covers native apps for Exchange Online, SharePoint Online and Teams on Entra-joined or Entra-registered Windows devices and MDM-managed Apple devices, browser support is still limited, and Microsoft says to pilot it in report-only mode first (Microsoft Learn: Token protection).

Conditional access decides what a session may do. Require a compliant or hybrid-joined device for anything sensitive, so a cookie replayed from an attacker's unmanaged VM hits a wall. Block legacy authentication. Use sign-in risk and user risk as conditions, so a medium-risk sign-in gets re-challenged and a high-risk user gets a forced reset and session revocation. If nobody on your side owns that policy set, hand it to Microsoft 365 managed services.

Then close the gap between "we revoked it" and "it stopped working." Microsoft Entra access tokens are valid for one hour by default, and a revoked session can keep working that long with a client that doesn't know better. Continuous access evaluation lets Exchange Online, SharePoint Online and Teams receive critical events, such as a disabled account, a password reset or a high-risk detection, and reject the token in near real time, with propagation latency of up to 15 minutes (Microsoft Learn: Continuous access evaluation).

MFA still matters, as long as it's the phishing-resistant kind. Passkeys and FIDO2 keys are bound to the real origin, so a proxy on a lookalike domain never gets a cookie to steal. The wider control baseline is in our plain-English CIS Controls IG1 guide.

None of the server-side work helps if the endpoint is already owned. Infostealer malware, usually arriving as a cracked installer, a fake browser update or a malicious ad, copies the browser's cookie store and cached tokens and ships them off in seconds. The cookies arrive at the attacker already authenticated, MFA already satisfied. That makes endpoint protection an identity control.

So: managed EDR on every device that signs in to company resources, the owner's laptop included. Tightly control browser extensions. Turn off browser profile sync for work profiles. When a device is confirmed infected, treat every account used on it as compromised: revoke sessions and refresh tokens, reset the password, review MFA methods and OAuth consents, then reimage.

A stolen session usually betrays itself by context. The same session or refresh token shows up from a new IP, network and user agent within minutes of a legitimate sign-in. Non-interactive sign-ins appear from places the user has never been. Shortly after, a new inbox rule starts hiding mail, an OAuth app gets consented, or MFA gains a method nobody recognizes.

In Entra ID Protection, alert on anomalous token, unfamiliar sign-in properties on non-interactive sign-ins, attacker in the middle, atypical travel and suspicious inbox manipulation rules; Microsoft calls out anomalous token as an indicator of token replay, and most of the detailed detections need the P2 tier (Microsoft Learn: ID Protection risk detections).

For your own apps, record IP, user agent and device fingerprint at session creation and compare on each request; a hard mismatch should step up authentication or end the session. Alert on refresh-token reuse. Automated monitoring can watch for all of this continuously; the response still needs a human with the authority to revoke sessions and reset accounts, which is where managed cybersecurity and privileged access management earn their keep.

Want someone to pressure-test this against your tenant? Start with a free IT assessment or talk to us.

We already enforce MFA. Does session hijacking still matter?

Yes. The attack happens after MFA succeeds, so the stolen cookie already carries the MFA claim. Phishing-resistant methods shrink the proxy route; infostealers and XSS don't care which second factor you used.

Does Microsoft Entra Token Protection cover web browsers?

Only partially. Microsoft lists browser-based support as limited to selected web apps and in preview, while native apps for Exchange Online, SharePoint Online and Teams on Entra-registered Windows devices and MDM-managed Apple devices are supported (Microsoft Learn: Token protection).

What's the first move when we suspect a hijacked session?

Revoke the user's sessions and refresh tokens in the identity provider, then reset the password and review MFA methods, inbox rules and app consents. Revocation comes first because a password reset alone doesn't kill a token that was already issued.