You use a unique password. You approve MFA. The website confirms your identity and lets you in.
From that point forward, the site usually does not ask for your password and second factor on every click. Instead, your browser presents a temporary session token—often stored in a cookie—to show that authentication already happened.
That convenience creates a second security boundary. If an attacker steals a valid session token, they may be able to impersonate the signed-in user without repeating the login process. The password can remain secret. MFA can remain enabled. The attacker simply reuses evidence that both checks were already completed.
This is session hijacking.
The short answer
A session cookie is a short-term secret that helps a website recognize an authenticated browser. When a valid cookie is copied into an attacker-controlled browser or used by malware, the service may treat the attacker as the existing signed-in user.
MFA protects the authentication event. It does not automatically protect every action taken afterward if the resulting session is stolen.
To reduce personal risk, keep browsers and devices updated, remove unnecessary extensions, avoid untrusted software, review active sessions, sign out unfamiliar devices, and reauthenticate important accounts after suspected compromise. Website operators must protect session tokens, enforce expiration, rotate and invalidate sessions, require reauthentication for sensitive actions, and monitor for suspicious session behavior.
What is a web session?
HTTP does not inherently remember who made the previous request. After a successful login, a website therefore creates a session that links future requests to the authenticated account.
The service sends the browser a session identifier or token. In many web applications, the browser stores and returns it as a cookie. The token is not normally a readable copy of your password. It is a temporary secret that tells the server, in effect: “This request belongs to the browser that already authenticated.”
The OWASP Session Management Cheat Sheet explains that an established session ID temporarily becomes equivalent to the authentication strength used to create it. NIST’s session-management guidance similarly describes a session secret that binds the user’s software to the service after authentication.
That token makes websites usable. Without it, you might have to enter your password and MFA code for every page, message, or button.
What is session hijacking?
Session hijacking occurs when an attacker obtains, predicts, fixes, or otherwise takes control of a valid session token and uses it to impersonate the legitimate user.
Modern, well-designed tokens should be random enough that guessing is impractical. Theft is often the more realistic concern. The attacker may extract a token from a compromised device, intercept it through a vulnerable application, capture it during an adversary-in-the-middle phishing flow, or obtain it through malicious browser code.
Once the token is replayed, the service may see a valid session rather than a new login.
How a stolen cookie can bypass MFA
1. The user signs in normally
The legitimate user enters a password or uses a passkey, then completes any required second factor.
2. The service creates a session
After successful authentication, the service issues a session token. The browser stores it and sends it with later requests.
3. The token is stolen
Malware, a malicious extension, vulnerable website code, an adversary-in-the-middle phishing system, or insecure token handling exposes the active session secret.
4. The attacker replays the token
The attacker presents the stolen token to the service from another environment.
5. The service accepts the existing session
If the token remains valid and the service does not detect suspicious context, it may grant access without displaying the login or MFA challenge again.
MFA has not been mathematically broken. The attacker has moved around the authentication checkpoint by stealing what the service issued after that checkpoint was passed.
Session hijacking vs stolen passwords
| Question | Password theft | Session hijacking |
|---|---|---|
| What is stolen? | A reusable login secret | An active session token |
| When is it used? | At the login screen | After authentication has already occurred |
| Will MFA appear? | Usually, when enabled | It may not appear until reauthentication is required |
| Does changing the password help? | Yes, for future password logins | Not always, unless existing sessions are also revoked |
| Typical response | Change password and strengthen MFA | Revoke sessions, change credentials, inspect the device and account |
| Main prevention | Unique passwords, passkeys, MFA | Secure devices, protected tokens, expiration, monitoring, reauthentication |
The two attacks can be combined. A phishing campaign may steal a password, relay the MFA step, and capture the resulting session cookie. Malware may collect both passwords and session data from a browser profile.
How session tokens are stolen
Information-stealing malware
Malware running on a device may search browser profiles for passwords, cookies, tokens, autofill data, cryptocurrency wallets, and other sensitive information. A user might encounter it through a fake update, pirated software, a malicious attachment, or a deceptive download.
Even a strong passkey cannot make a fully compromised, unlocked endpoint trustworthy. The attacker may wait until the legitimate user authenticates, then abuse the resulting session.
Malicious or overprivileged browser extensions
Extensions can have powerful access to websites and browsing data. A malicious extension—or a legitimate extension later compromised—may observe or alter page content, depending on its permissions and the browser’s protections.
Install as few extensions as practical. Remove those you no longer use and review permissions after updates.
Cross-site scripting
A cross-site scripting vulnerability allows attacker-controlled code to run in the context of a trusted website. Properly configured HttpOnly cookies are not readable by ordinary page JavaScript, but XSS can still perform actions as the user or target other exposed tokens and application data.
This is primarily a website-security responsibility. Users cannot fix vulnerable application code themselves.
Adversary-in-the-middle phishing
A sophisticated phishing system may proxy traffic between the victim and the real service. The victim sees a convincing login flow, enters the password, and completes MFA. The attacker relays each step in real time and captures the authenticated session that follows.
Code-based MFA can be phished this way. Phishing-resistant passkeys and FIDO security keys are designed to bind authentication to the legitimate domain, which blocks the usual credential-relay step. Endpoint compromise and post-authentication session theft remain separate concerns.
Insecure transport or token handling
HTTPS protects tokens while they travel between browser and service. Websites should mark session cookies Secure, avoid exposing tokens in URLs or logs, restrict their domain and path, and use appropriate SameSite and HttpOnly settings.
TLS does not protect a token after malware gains access to the endpoint or if vulnerable application code exposes it.
Physical access to an unlocked device
Someone who can use an unlocked, signed-in browser may not need to steal the token at all. They can act through the existing session. Screen locks, full-disk encryption, and separate user accounts help reduce this risk.
Can passkeys prevent session hijacking?
Passkeys significantly improve the login step. They resist ordinary credential phishing and eliminate password reuse. They do not remove the need for secure session management.
After the passkey authenticates the user, the service may still issue a conventional bearer session token. If that token is stolen and can be replayed, the attacker may not need the passkey.
Emerging device-bound session approaches aim to make replay harder by requiring cryptographic proof from the original device instead of accepting possession of a copied bearer token alone. Adoption and implementation vary, so users should not assume every service provides this protection.
For the authentication basics, see Passkeys vs Passwords vs MFA.
Warning signs of a hijacked session
Session theft can be quiet because it may not generate a new-login challenge. Watch for:
Messages, posts, files, or purchases you did not create.
New mailbox-forwarding or filtering rules.
Security settings or recovery details changing unexpectedly.
Connected apps, API grants, or devices you do not recognize.
Activity from unfamiliar locations without a matching login alert.
Sessions that remain active after you changed the password.
Notifications that sensitive data was viewed or exported.
Contacts receiving unusual messages from your account.
Some services show recent sessions with device, location, browser, and last-active information. Location can be approximate, especially with mobile networks or VPNs, so evaluate several signals together.
What to do if you suspect session hijacking
1. Use a trusted device
If you suspect the normal device is infected, do not rely on it for recovery. Use another updated device or follow your organization’s incident-response process.
2. Revoke active sessions
Use Sign out everywhere, Log out all devices, or the service’s session-management page. Remove unfamiliar devices and remembered browsers.
This step is essential. A password change does not always invalidate every existing session.
3. Change the password
Replace the account password with a new, unique credential. If it was reused, update every account that shared it.
4. Protect authentication and recovery
Review registered passkeys, security keys, authenticator apps, phone numbers, backup codes, and recovery addresses. Remove anything unfamiliar and generate new recovery codes when appropriate.
5. Inspect high-value account settings
For email, check forwarding rules, delegates, recovery options, application passwords, and connected services. For financial or shopping accounts, review transactions and stored payment details. For cloud storage, inspect sharing links and access history.
6. Scan, update, or rebuild the device
Update the operating system, browser, and security tools. Remove suspicious applications and extensions. If information-stealing malware is confirmed or strongly suspected, professional guidance or a clean operating-system reinstall may be necessary.
7. Notify the organization
Report suspected session theft involving a work, school, or managed account. Administrators may need to revoke identity-provider sessions, application sessions, access tokens, refresh tokens, and connected-app permissions separately.
Why changing the password may not be enough
A password and a session token are different secrets with different lifecycles. Changing the password blocks future logins that use the old password, but the service must separately decide what happens to sessions already issued.
Well-designed recovery flows often revoke or reevaluate sessions after a password change or high-risk event. Not every service behaves the same way. Explicitly sign out other devices and review the session list whenever compromise is suspected.
Federated sign-in adds another layer. Your identity provider and each connected service may maintain independent sessions. Signing out of one does not always terminate the others. NIST notes that identity-provider and relying-party sessions can be established and ended separately.
How to reduce your personal risk
Keep the operating system, browser, and extensions updated.
Install software only from sources you trust.
Avoid pirated programs, cracks, and fake browser updates.
Remove extensions you no longer need.
Lock devices whenever you step away.
Use separate browser profiles or device accounts for sensitive work.
Review active sessions for email, finance, social, and cloud accounts.
Use passkeys or hardware security keys to resist credential phishing.
Require reauthentication for sensitive settings when the service offers it.
Sign out of shared or public devices and avoid saving sessions on them.
Treat unexpected MFA prompts as an attack signal.
Secure the recovery email and password manager before lower-value accounts.
The goal is not to delete every cookie after every visit. Sessions are necessary for usable web applications. The goal is to protect the device, minimize unnecessary exposure, and terminate sessions when they should no longer be trusted.
What website owners should implement
Strong token generation
Session identifiers must be unpredictable and generated with a cryptographically secure source of randomness. Tokens should contain no readable personal information.
Secure cookie settings
For browser sessions, use HTTPS and appropriate Secure, HttpOnly, SameSite, domain, path, and lifetime settings. These attributes address different attack paths and should be configured together.
Rotation and invalidation
Regenerate the session identifier after authentication and privilege changes. Revoke sessions on logout, expiration, account compromise, and other high-risk events.
Idle and absolute timeouts
An idle timeout limits an unattended session. An absolute timeout limits total session life even when activity continues. The correct values depend on the account’s risk and context.
Reauthentication for sensitive actions
Ask for fresh authentication before changing credentials, adding recovery methods, viewing highly sensitive data, transferring money, or performing administrator actions.
Session monitoring
Evaluate risk signals such as device characteristics, IP information, geolocation, timing, usage patterns, and sudden changes in behavior. When risk rises, reauthenticate, terminate the session, or alert the security team.
Monitoring must be proportionate and privacy-aware. A location change alone is not proof of attack.
XSS and CSRF defenses
Prevent cross-site scripting, protect state-changing requests against cross-site request forgery, and avoid placing sensitive bearer tokens in JavaScript-accessible storage without a carefully justified design.
User-visible controls
Give people a clear session list, meaningful security notifications, a reliable Sign out everywhere control, and understandable device-removal options.
Session hijacking and MFA fatigue are different
MFA fatigue pressures the user to approve a new authentication event. Session hijacking steals or abuses the result of an authentication event that already succeeded.
| MFA fatigue | Session hijacking |
|---|---|
| Attacker needs the victim to approve | Attacker may need no new user action |
| Happens during authentication | Happens after authentication |
| Number matching can reduce blind approval | Token protection and reauthentication are central |
| Phishing-resistant MFA improves the login | Secure session design protects what follows |
Read MFA Fatigue Attacks Explained for the full push-bombing sequence and response checklist.
Frequently asked questions
Is a session cookie the same as my password?
No. It is usually a temporary token issued after authentication. However, while valid, it may grant access to the authenticated session and must be protected like a sensitive secret.
Can someone log in without knowing my password?
Yes, if they obtain a valid session token or abuse an already-unlocked device. The service may treat the request as part of the existing session rather than a new login.
Does MFA stop session hijacking?
MFA protects the process of creating a session. It does not automatically stop replay of a stolen bearer session token. Reauthentication, secure token handling, monitoring, and session invalidation provide additional protection.
Will changing my password remove a stolen session?
It depends on the service. Some revoke existing sessions automatically; others do not. Use Sign out everywhere and review active sessions after suspected compromise.
Should I clear all browser cookies regularly?
Routine cookie deletion is not a complete session-hijacking defense. It can end local sessions but does not secure an infected device or guarantee that a copied token has been revoked server-side. Use the service’s session controls and address the cause of exposure.
Are passkeys useless against cookie theft?
No. Passkeys provide major protection against password reuse and credential phishing. Session security is a separate layer that still needs protection after any successful authentication method.
The takeaway
Passwords, passkeys, and MFA protect the front door. Session tokens let you move around after that door opens.
A stolen session can allow an attacker to reuse an already-approved login. That is why strong authentication must be paired with secure devices, protected tokens, meaningful expiration, session monitoring, reauthentication, and reliable revocation.
If you suspect session theft, use a trusted device, sign out all sessions, change exposed credentials, inspect authentication and recovery methods, and investigate the device that held the session.
Explore further: Discover interactive science and technology explainers at ExploreSims.com.