Session hijacking is a cybersecurity attack in which someone steals, predicts, fixes, or otherwise obtains a valid session identifier and uses it to impersonate an authenticated user.
After a user signs in, a website or application usually creates a session. The session allows the user to continue using the service without entering their password for every request.
If an attacker obtains the session token, the application may treat them as the legitimate user. The attacker may not need to know the victim’s password or complete multi-factor authentication because those steps were already completed when the session was created.
A successful attack may allow someone to:
- Read private information
- Send messages
- Change account settings
- Access stored documents
- Make purchases
- Create API keys
- Disable security protections
- Perform administrative actions
- Take over the account
OWASP describes session hijacking as compromising a valid session token through theft, prediction, sniffing, client-side attacks, or interception and then using it to gain unauthorized access. OWASP’s Session Hijacking overview explains the attack.
What Is a User Session?
A user session is the application’s way of remembering an authenticated user across multiple requests.
HTTP is stateless. By itself, one request does not automatically know who sent an earlier request. Applications solve this by issuing a session identifier after login.
The identifier may be stored in:
- A browser cookie
- An authorization header
- Local application storage
- A mobile application
- A desktop client
- A server-side session store
- A short-lived access token
The client sends the identifier with later requests. The server uses it to locate the session and determine the user’s identity, permissions, and security state.
What Is a Session Token?
A session token, session ID, or session cookie is a value that represents an authenticated session.
The token may be a random identifier linked to server-side session data. In other systems, the token may contain signed claims about the user and session.
A secure token should be:
- Unpredictable
- Unique
- Protected in transit
- Protected from client-side scripts where possible
- Short-lived enough for the application’s risk
- Revocable
- Replaced after important identity changes
- Free from unnecessary personal information
Anyone who possesses a bearer-style session token may be treated as the authenticated user until the token expires or is revoked.
How Does Session Hijacking Work?
A typical session-hijacking attack follows this pattern:
- The user signs in successfully.
- The application creates an authenticated session.
- A session token is stored on the user’s device.
- The attacker steals, predicts, fixes, or obtains the token.
- The attacker sends the token to the application.
- The application finds the valid session.
- The server treats the attacker as the authenticated user.
The attacker is not necessarily defeating the password or MFA system. They are taking control of the trusted result created by that system.
OWASP notes that disclosure, capture, prediction, brute force, or fixation of a session identifier can allow an attacker to impersonate the victim. OWASP’s Session Management Cheat Sheet provides comprehensive defensive guidance.
Why Is Session Hijacking Dangerous?
A stolen session can provide immediate authenticated access.
The attacker may inherit:
- The victim’s identity
- Current account permissions
- Administrator privileges
- Approved authentication state
- Completed MFA state
- Access to confidential information
- Trusted-device status
- Active workflow context
Possible consequences include:
- Account takeover
- Financial fraud
- Identity theft
- Exposure of personal information
- Theft of business data
- Unauthorized messages
- Creation of persistent access
- Disabling account protections
- Administrative compromise
- Movement into connected services
The impact depends on the victim’s role and whether the application requires reauthentication for sensitive actions.
Common Types of Session Hijacking
Session Cookie Theft
Many web applications store the session identifier inside a browser cookie.
If an attacker steals that cookie, they may be able to place it in another browser or client and access the victim’s session.
A stolen session cookie can remain useful until:
- The session expires
- The user logs out
- The server revokes it
- Security state changes
- The application detects the theft
OWASP notes that stealing a valid session cookie can have an impact similar to stealing credentials for the lifetime of that session. OWASP’s Cookie Theft Mitigation Cheat Sheet discusses detection and containment.
Cross-Site Scripting Session Theft
A Cross-Site Scripting, or XSS, vulnerability may allow malicious JavaScript to run inside the trusted application.
If the session token is accessible to JavaScript, the malicious script may attempt to steal it.
The HttpOnly cookie attribute can prevent ordinary client-side JavaScript from reading a session cookie. However, XSS may still perform authenticated actions from within the victim’s browser even when it cannot read the cookie.
Preventing XSS remains essential.
Network Session Sniffing
If a session token travels over an unencrypted or improperly protected connection, someone monitoring the network may capture it.
This risk is especially serious on shared or hostile networks.
Applications should use HTTPS for:
- Login
- Authenticated pages
- APIs
- Static resources that interact with authenticated pages
- WebSocket connections
Session cookies should use the Secure attribute so browsers do not transmit them over ordinary HTTP.
Man-in-the-Middle Session Hijacking
A man-in-the-middle attacker positions themselves between the user and service.
If transport security is absent or certificate validation is broken, the attacker may intercept session tokens or modify traffic.
Correct TLS deployment and certificate validation reduce this risk.
Man-in-the-Browser Attack
Malware or a malicious browser extension may operate inside the user’s browser.
It may:
- Read page content
- Capture session information
- Modify transactions
- Perform actions through the active session
- Steal authentication tokens
- Interfere with security prompts
Server-side monitoring and transaction-specific verification can reduce the impact, but affected devices may need to be cleaned or rebuilt.
Session Prediction
A session prediction attack occurs when session identifiers are generated using a predictable pattern.
An attacker may study multiple values and attempt to calculate or guess another valid token.
Secure session identifiers require strong cryptographic randomness and sufficient entropy.
Session Brute Force
An attacker may submit large numbers of possible session identifiers until one matches an active session.
The risk increases when tokens are:
- Short
- Predictable
- Partly fixed
- Generated from timestamps
- Derived from user information
- Created with weak randomness
Strong token generation makes successful guessing impractical.
Session Fixation
Session fixation is a form of hijacking in which the attacker causes the victim to use a session identifier already known to the attacker.
The victim then authenticates using that session. If the application continues using the same identifier after login, the attacker can reuse it to access the authenticated account.
MITRE classifies this weakness as CWE-384. MITRE’s Session Fixation entry explains that applications should invalidate the old session and create a new one when authentication occurs.
Session Replay
A replay attack reuses a previously captured valid session token or authenticated request.
The token may still be accepted if the application does not:
- Expire it promptly
- Revoke it
- Detect reuse
- Bind it to appropriate context
- Require fresh authorization for sensitive operations
Short lifetimes, token rotation, nonces, and transaction-specific authorization can reduce replay risk.
Stolen Refresh Token
Modern applications may use short-lived access tokens and longer-lived refresh tokens.
A stolen refresh token may allow an attacker to obtain new access tokens repeatedly.
Refresh tokens should be:
- Stored securely
- Rotated after use
- Revocable
- Bound to the intended client where practical
- Monitored for reuse
Reuse of a rotated refresh token can be a strong signal of token theft.
Session Hijacking Through Malware
Malware may steal tokens from:
- Browser data
- Application storage
- Memory
- Network traffic
- Temporary files
- Desktop clients
- Developer tools
Information-stealing malware often targets authentication cookies and tokens because they may bypass passwords and MFA.
Browser Extension Theft
A malicious or compromised browser extension may access webpage content, cookies, storage, or requests depending on its permissions.
Users should install extensions only from trusted sources and remove unnecessary ones. Organizations can enforce browser-extension policies on managed devices.
Session Hijacking Through Logs
Session tokens may be exposed when applications record them in:
- Access logs
- Debug logs
- Error messages
- Analytics platforms
- Monitoring systems
- Support tickets
- Screenshots
Authentication secrets should be redacted before logging.
URL-Based Session Leakage
Placing session identifiers in URLs can expose them through:
- Browser history
- Referrer headers
- Server logs
- Bookmarks
- Shared links
- Screenshots
- Analytics tools
Session identifiers should normally be stored in securely configured cookies or appropriate authorization headers instead.
Session Hijacking Through Referer Leakage
If a sensitive token appears in a URL, the browser may send that URL as a referrer when loading another resource or following a link.
This can disclose the token to a third party.
Applications should not place session tokens in URLs and should set an appropriate Referrer-Policy.
WebSocket Session Hijacking
WebSocket connections often rely on the same browser cookies used by the main application.
If the server accepts cross-origin connections without validating the Origin header or requiring appropriate anti-CSRF protection, a malicious site may open an authenticated WebSocket through the victim’s browser.
This attack is sometimes called Cross-Site WebSocket Hijacking.
Mobile Session Hijacking
Mobile applications may expose sessions through:
- Insecure local storage
- Debug logs
- Backup files
- Weak certificate validation
- Embedded browser components
- Shared clipboard data
- Device malware
- Long-lived tokens
Mobile tokens should be stored using platform-provided secure storage and transmitted only through properly validated TLS connections.
QR Login Hijacking
Some applications allow a user to sign in by scanning a QR code.
If a victim is tricked into scanning a code associated with an attacker’s login session, the victim may unknowingly authorize that session.
Login confirmations should clearly display the target device, location, and account action before approval.
Privileged Session Hijacking
Administrative and service-account sessions are especially valuable because they may provide broad access to users, configuration, secrets, or infrastructure.
Privileged sessions should have:
- Shorter lifetimes
- Strong MFA
- Device or certificate requirements
- Detailed monitoring
- Reauthentication for high-impact actions
- Rapid revocation
Session Hijacking vs. Session Fixation
Session hijacking is the broader attack in which an attacker takes control of a valid session.
Session fixation is one way to achieve that result. The attacker supplies or knows the session identifier before the victim logs in.
Other hijacking methods steal or predict a session after it has already been authenticated.
Session Hijacking vs. Authentication Bypass
Authentication bypass defeats or avoids the identity-checking process.
Session hijacking reuses the trusted authenticated state of another user.
Both may provide account access without the attacker knowing the password, but they target different parts of the authentication system.
Session Hijacking vs. CSRF
Cross-Site Request Forgery, or CSRF, tricks the victim’s browser into performing an unwanted action while the attacker may never learn the session token.
Session hijacking gives the attacker control or possession of the session itself.
CSRF is generally limited by what the attacker can cause the browser to send and what responses they can observe. Hijacking may allow direct access as the user.
Session Hijacking vs. Credential Theft
Credential theft exposes a password, security key, one-time code, or another authentication factor.
Session hijacking steals the authenticated session created after those credentials were accepted.
Changing the password may not immediately stop an attacker if the application does not revoke existing sessions.
Session Hijacking vs. Cookie Theft
Cookie theft is one method of session hijacking.
Not every cookie contains a session token, and sessions can also be represented through headers or other token formats.
Session hijacking refers to the outcome: unauthorized control of the authenticated session.
Warning Signs of Session Hijacking
Users and security teams may notice:
- Login activity from an unfamiliar location
- A session moving between distant regions quickly
- Sudden browser or device changes
- Session use from multiple networks simultaneously
- Account changes the user did not make
- Messages or transactions initiated without permission
- New API keys or connected applications
- MFA settings being changed
- Security notifications being disabled
- Session tokens reused after rotation
- Expired tokens being accepted
- Administrator activity from an unusual device
- Large downloads during an established session
- Requests continuing after logout
- Unusual changes in user-agent or device characteristics
- Refresh-token reuse
- Many guessed session IDs
- Sessions created without a matching login event
Changes in IP address or browser information do not automatically prove theft. Mobile networks, VPNs, privacy tools, and travel can create legitimate changes.
Detection should combine multiple signals.
What Causes Session Hijacking?
Common causes include:
- Session tokens exposed to JavaScript
- Cross-Site Scripting
- Missing HTTPS
- Missing Secure cookie attributes
- Predictable session identifiers
- Excessively long session lifetimes
- Missing token rotation
- Sessions remaining active after logout
- Session fixation
- Tokens stored in URLs
- Tokens written to logs
- Insecure mobile storage
- Malware
- Unsafe browser extensions
- Missing revocation
- Weak refresh-token handling
- Improper WebSocket origin validation
- Failing to reauthenticate sensitive actions
Session security requires protecting the complete token lifecycle.
How Can Developers Prevent Session Hijacking?
Use Cryptographically Random Session Identifiers
Session IDs should contain sufficient unpredictable entropy and be generated with a cryptographically secure random source.
Do not derive tokens from:
- Usernames
- Email addresses
- Timestamps
- Sequential numbers
- Device IDs
- IP addresses
- Weak random generators
OWASP recommends at least 64 bits of entropy for session identifiers, while noting that effective security depends on unpredictability, valid-session volume, and guessing rate. OWASP’s Session Management Cheat Sheet provides detailed guidance.
Use HTTPS Everywhere
Protect the entire authenticated application with HTTPS, not only the login page.
Use HTTP Strict Transport Security where appropriate to instruct browsers to use secure connections.
Set the Secure Cookie Attribute
A session cookie with the Secure attribute is sent only over HTTPS.
Without it, a browser may expose the cookie in an unencrypted HTTP request under certain conditions.
Set the HttpOnly Attribute
HttpOnly prevents ordinary JavaScript from reading the session cookie.
This makes straightforward cookie theft through XSS more difficult, although it does not prevent malicious scripts from performing actions inside the victim’s active session.
Configure SameSite Appropriately
The SameSite cookie attribute controls when browsers attach cookies to cross-site requests.
Appropriate settings can reduce CSRF and some cross-site session abuse.
The correct value depends on legitimate cross-site workflows, federated login, and application architecture.
Restrict Cookie Scope
Set narrow cookie:
- Domain
- Path
- Lifetime
Avoid sharing high-value authentication cookies with unrelated subdomains or application paths.
A vulnerability in one subdomain should not automatically expose sessions for every service.
Rotate the Session ID After Login
Invalidate the pre-authentication identifier and create a fresh session after successful login.
Also rotate the session after:
- MFA completion
- Privilege escalation
- Password reset
- Account recovery
- Role change
- Other sensitive authentication-state changes
This prevents session fixation and reduces token reuse.
Implement Idle and Absolute Timeouts
Use both:
- Idle timeout: Ends a session after a period without activity.
- Absolute timeout: Ends a session after a maximum lifetime regardless of activity.
High-risk accounts and applications should generally use shorter limits.
Revoke Sessions on Logout
Logout should invalidate the server-side session or otherwise make the token unusable.
Deleting the browser cookie without invalidating the underlying session may leave the token usable if an attacker already copied it.
Revoke Sessions After Security Changes
Applications should invalidate relevant sessions after:
- Password changes
- MFA changes
- Account recovery
- Suspicious activity
- Account suspension
- Role removal
- Token theft reports
- Email or recovery changes where risk warrants it
Allow users to view and revoke active sessions.
Rotate Refresh Tokens
Use refresh-token rotation so each successful use produces a new token and invalidates the old one.
If an old token is reused, revoke the related token family and investigate possible theft.
Protect Against XSS
Prevent XSS through:
- Context-appropriate output encoding
- Safe templates
- HTML sanitization
- Avoiding dangerous browser APIs
- Content Security Policy
- Secure dependency management
- HttpOnly cookies
XSS can abuse an authenticated session even when it cannot directly read the cookie.
Keep Tokens Out of URLs
Do not place session tokens in query strings or URL paths.
Use secure cookies or authorization headers as appropriate.
Do Not Log Session Tokens
Redact authentication cookies, bearer tokens, reset links, authorization headers, and other session credentials from logs.
Restrict access to logs containing sensitive authentication information.
Require Reauthentication for Sensitive Actions
Require the user’s current password, MFA, or another strong confirmation before:
- Changing passwords
- Replacing MFA
- Updating recovery information
- Creating API keys
- Transferring funds
- Deleting an account
- Changing administrator roles
- Viewing highly sensitive information
OWASP recommends current-credential verification for sensitive account changes to reduce the impact of session hijacking and related attacks. OWASP’s Authentication Cheat Sheet discusses this control.
Use Transaction-Specific Authorization
For high-impact operations, bind approval to the exact transaction.
The confirmation should clearly show:
- Amount
- Destination
- Resource
- Action
- Account
Approval for one transaction should not authorize another.
Store Mobile Tokens Securely
Use operating-system-provided secure storage.
Avoid storing long-lived session tokens in:
- Plaintext files
- General application preferences
- Debug logs
- Clipboard data
- Public storage
- Unencrypted backups
Validate WebSocket Origins
For browser-based WebSockets:
- Validate the
Originheader - Use authentication at the handshake
- Apply authorization to every message
- Use CSRF-style protections where appropriate
- Close connections when the session expires or is revoked
Monitor Session Context
Applications may compare signals such as:
- Device characteristics
- Browser information
- Network location
- Session age
- Authentication strength
- Token reuse
- Request behavior
These signals should support risk detection rather than create brittle rules that lock out legitimate users.
Use Step-Up Authentication
When session behavior becomes risky, require additional authentication before sensitive actions.
For example, a new location combined with a high-value transaction may justify an MFA challenge.
Provide Active Session Management
Allow users to review:
- Active devices
- Approximate locations
- Recent activity
- Session creation time
- Last use
Users should be able to revoke individual sessions or sign out everywhere.
Can MFA Prevent Session Hijacking?
MFA protects the login process, but it does not automatically protect an already authenticated session.
If an attacker steals the session token after MFA is completed, the application may treat the attacker as already verified.
MFA remains important, especially when combined with:
- Short session lifetimes
- Session monitoring
- Reauthentication
- Token binding where supported
- Secure devices
- Rapid revocation
Can Changing a Password Stop Session Hijacking?
Only if the service revokes existing sessions after the password change.
Some applications leave active sessions valid, allowing an attacker to remain signed in.
After suspected hijacking, users should choose “sign out all sessions” when available.
Does HTTPS Completely Prevent Session Hijacking?
No.
HTTPS protects tokens in transit, but sessions may still be stolen through:
- XSS
- Malware
- Browser extensions
- Logs
- Insecure storage
- Phishing
- Token leakage
- Server compromise
HTTPS is essential but must be combined with secure token handling.
Can a Web Application Firewall Stop Session Hijacking?
A WAF may detect token-guessing attempts, unusual requests, or some XSS payloads.
It cannot reliably identify every stolen session because the attacker may present a completely valid token.
Applications need secure token management, behavioral detection, reauthentication, and revocation.
How Should Session Hijacking Be Tested?
Testing must be performed only with explicit authorization.
A controlled review should examine:
- Session-token randomness
- Cookie attributes
- HTTPS enforcement
- Session rotation after login
- Rotation after privilege changes
- Logout invalidation
- Idle timeout
- Absolute timeout
- Password-change behavior
- MFA-change behavior
- Refresh-token rotation
- Concurrent sessions
- Session fixation
- Token exposure in URLs and logs
- Mobile token storage
- WebSocket session handling
- Detection of token reuse
Testing should use designated test accounts and tokens. Real user sessions should never be captured or reused without explicit authorization.
How Can Organizations Detect Session Hijacking?
Useful monitoring sources include:
- Authentication logs
- Session creation and revocation
- API gateway records
- Device information
- Network and geographic data
- Refresh-token events
- MFA activity
- Account changes
- Administrative actions
- Data-download activity
- Endpoint security alerts
High-value detections include:
- Refresh-token reuse
- One session used simultaneously from distant locations
- Session continuation after logout
- Sensitive actions from a new device
- MFA changes followed by rapid account changes
- Large downloads from an old session
- Administrator sessions moving between devices unexpectedly
- Requests using invalidated tokens
What Should an Organization Do After Detecting Session Hijacking?
Revoke the Affected Session
Immediately invalidate the stolen token and any related refresh tokens.
If the scope is uncertain, revoke all sessions for the affected account.
Protect the Account
Depending on the incident:
- Require a password reset
- Require MFA re-enrollment
- Revoke recovery codes
- Remove unfamiliar devices
- Disable suspicious connected applications
- Revoke unauthorized API keys
- Temporarily lock high-risk functions
Preserve Evidence
Collect:
- Session records
- Authentication events
- Device information
- Network addresses addresses
- Account changes
- API activity
- File downloads
- Administrative actions
- Token-rotation events
- Security notifications
Follow established incident-response and privacy procedures.
Determine What the Attacker Did
Investigators should identify:
- When the session was stolen
- How long it was used
- Which resources were accessed
- Whether data was downloaded
- Which settings changed
- Whether API keys were created
- Whether MFA or recovery information changed
- Whether the attacker established persistence
- Whether connected systems were accessed
Reverse Unauthorized Changes
Restore:
- Recovery information
- Account email addresses
- MFA settings
- Roles
- Sharing permissions
- Connected applications
- Modified or deleted data
- Financial changes where possible
Fix the Root Cause
The response should address how the token was compromised.
Possible fixes include:
- Correcting XSS
- Enforcing HTTPS
- Securing cookies
- Rotating tokens
- Reducing session lifetime
- Removing tokens from logs
- Fixing session fixation
- Securing mobile storage
- Improving malware defenses
- Restricting browser extensions
- Adding session-theft detection
Notify Affected Users
Explain:
- What happened
- Which account activity was affected
- What was accessed or changed
- Which sessions were revoked
- What the user should do
Follow applicable legal and regulatory requirements.
Continue Monitoring
Watch for:
- Reuse of revoked tokens
- New account access
- Use of downloaded data
- Suspicious API credentials
- Further account-recovery attempts
- New persistence
- Related attacks against other users
What Should a User Do After Suspected Session Hijacking?
If you believe someone is using your active session:
- Open the service through its official application or website.
- Sign out all sessions.
- Change your password.
- Enable or reset MFA.
- Review active devices.
- Remove unfamiliar connected applications.
- Revoke unknown API keys.
- Check recovery email addresses and phone numbers.
- Review recent messages, downloads, purchases, and settings.
- Scan the device for malware.
- Remove suspicious browser extensions.
- Contact the service provider.
Perform these steps from a trusted device when possible.
Can Session Hijacking Lead to Account Takeover?
Yes.
The attacker may already have nearly complete control while the stolen session remains valid.
They can make the takeover persistent by changing the password, recovery details, MFA factors, connected identities, or API credentials.
Sensitive account changes should require reauthentication.
Is Session Hijacking Only a Website Attack?
No.
It can affect:
- Mobile applications
- Desktop software
- APIs
- Cloud platforms
- WebSockets
- Single sign-on systems
- Gaming services
- Enterprise applications
- Internet of Things platforms
Any system that uses a reusable token to represent authenticated state may be affected.
