What Is Session Hijacking

The most direct form of session hijacking is simply obtaining the raw value of a valid session cookie and replaying it.

A session cookie is effectively a bearer credential: in many applications, possession of the correct value is sufficient to access the session it represents. An attacker who obtains that value can often present it from a different machine, browser, or location and have the server treat their requests as belonging to the authenticated user. From the application's perspective, the important question is often not who is presenting the cookie, but simply whether the presented session identifier maps to a valid authenticated session.

Common real-world sources of raw cookie theft include:

Physical or shared-device access. A user leaves an authenticated browser session accessible to the next person using the device, particularly on public or shared computers where the previous user did not properly log out. This ties directly back to session lifecycle, logout must be a real server-side event that invalidates the session, not merely a client-side change that hides the logged-in interface.

Browser extensions with excessive permissions. A malicious or overly privileged extension may be able to access sensitive browser data, depending on its permissions and the browser's security model.

Malware running on the victim's device. Code executing locally may be able to access browser data, session information, or authenticated sessions directly.

Improperly secured browser sync or backup data. If browser profiles, backups, or synchronized data containing authentication state are exposed, an attacker may gain access to active session material.

These threats illustrate an important limitation of the cookie protections discussed in session cookie attribute

Secure, HttpOnly, and SameSite do not make a session cookie impossible to steal. They protect against specific classes of exposure:

Secure helps prevent the cookie from being transmitted over an unencrypted HTTP connection.

HttpOnly prevents ordinary client-side JavaScript from reading the cookie through APIs such as document.cookie.

SameSite restricts when the browser automatically includes the cookie in certain cross-site requests.

None of these protections are designed to stop an attacker with direct access to the victim's device, browser profile, or browser internals from obtaining session material through other means.

The broader principle is:

Cookie flags protect the paths by which a cookie is sent or exposed to web content. They do not protect against an attacker who already controls, or can directly inspect, the environment storing the cookie.

Token leakage occurs when a session identifier ends up somewhere it was never intended to be exposed not because an attacker actively steals it, but because the application itself handles the credential in an unsafe way.

A session token is a credential. Anyone who obtains a valid token may be able to replay it and take over the session it represents. The danger, therefore, is not limited to direct attacks such as malware or cookie theft. A token can also be exposed simply because the application places it somewhere that gets copied, logged, cached, or forwarded as part of normal operation.

One of the most common examples is a session identifier appearing in a URL.

Session identifier ends up in a URL
   (either intentionally, or because session data is
    accidentally included in an unrelated parameter)
        ↓
The URL can now propagate into places the application
never intended the credential to reach:
   → Server access logs
   → Proxy, cache, or monitoring infrastructure
   → Browser history
   → Bookmarks and shared links
   → Potentially the Referer header when the browser
     loads third-party resources or navigates elsewhere

The Referer case is particularly important because the application may not explicitly send the token anywhere. If the site's referrer policy allows the relevant URL information to be included, the browser can automatically send it as part of an ordinary request to another destination.

For example, a page containing a session ID in its URL might load an analytics script, embedded content, or another external resource. Depending on the referrer policy and the relationship between the two origins, information from the current URL may be included in the request to that external service.

The problem is not that the third party necessarily did anything malicious. The credential was placed in a location designed to be propagated.

Other forms of token leakage are less visible but follow the same pattern:

Other common leakage sources:

   Verbose error or debug pages that expose
   request headers or authentication data
           ↓
   General request logging that records session
   or authorization values without redaction
           ↓
   Support tickets, bug reports, or diagnostic exports
   containing "the full request"
           ↓
   A live session credential is copied into a system
   where it was never intended to exist

In all of these cases, there may be no active attacker involved at the moment the leak occurs. The application or its surrounding infrastructure creates the exposure first. An attacker only needs to discover, access, or obtain the leaked credential later.

Defending Against Token Leakage:

Session identifiers should never appear in URLs:

A session ID should be transported using the session cookie rather than being embedded in query parameters, paths, links, redirects, or other locations likely to be logged or shared.

Applications must also treat session tokens and authorization credentials as sensitive data throughout their operational infrastructure.

Defense:

   Keep the session ID in a cookie
        +
   Never place session credentials in URLs
        +
   Apply Secure / HttpOnly / appropriate SameSite
   protections to the session cookie
        +
   Redact session IDs, cookies, Authorization headers,
   and other credentials before they enter:
      → Logs
      → Error reports
      → Monitoring systems
      → Analytics pipelines
      → Support tickets
      → Diagnostic exports
        ↓
✓ Significantly reduced token leakage surface

The broader principle is:

A session token is a credential, not ordinary application data.

Any location where it can be copied, logged, cached, displayed, forwarded, exported, or retained should be treated as a potential credential-exposure boundary.

Cross-site scripting can become a direct mechanism for session theft.

If an attacker can exploit an XSS vulnerability and cause arbitrary JavaScript to execute in the victim's browser under the application's origin, that script executes within the security context of the vulnerable site. Historically, one of the most direct uses of this access has been to read the victim's session cookie and send its value to an attacker-controlled server.

The attack flow is conceptually simple:

Application contains an XSS vulnerability
        ↓
Attacker causes malicious JavaScript to execute
in the victim's browser under the application's origin
        ↓
The script attempts to read:
document.cookie
        ↓
Session cookie is exposed to the script
        ↓
Cookie value is sent to the attacker
        ↓
Attacker replays the stolen session credential
        ↓
✓ Session hijacked

This is where the HttpOnly flag discussed in section provides a direct defense.

A cookie marked HttpOnly is not accessible through ordinary client-side JavaScript APIs such as document.cookie.

XSS executes in the victim's browser
        ↓
Malicious script attempts:
document.cookie
        ↓
Session cookie is marked HttpOnly
        ↓
The session cookie value is not exposed
to the JavaScript
        ↓
✗ Direct cookie theft blocked

This distinction is important:

HttpOnly protects the cookie value from ordinary script access. It does not prevent the XSS vulnerability itself.

An attacker who can execute JavaScript in the victim's authenticated browser may still be able to perform actions as that user without ever learning the raw session token.

For example:

Victim has an authenticated session
        ↓
XSS executes JavaScript in the victim's browser
        ↓
Malicious script sends an authenticated request
to the application's own origin
        ↓
The browser automatically attaches the session cookie
according to normal cookie rules
        ↓
Server processes the request as the victim
        ↓
Attacker may perform actions using
the victim's authenticated session

The key point is that HttpOnly restricts access to the cookie value. It does not prevent the browser from using that cookie when making requests.

The following distinction is therefore essential:

Attack

Can HttpOnly help?

Why?

JavaScript reads the raw session cookie

Yes

The cookie is not exposed through document.cookie.

JavaScript sends requests as the authenticated user

No, not by itself

The browser can still attach the cookie to eligible requests.

The underlying XSS vulnerability

No

HttpOnly does not remove the attacker's ability to execute script.

This means an XSS vulnerability remains serious even when every session cookie is correctly marked HttpOnly.

HttpOnly is an important defense-in-depth control, not a substitute for fixing XSS.

It prevents an attacker from simply reading and exporting the session credential, but a script running inside the victim's authenticated browser may still be able to act with that user's authority.

On an unencrypted HTTP connection, a session cookie travels across the network without transport-layer encryption.

Victim makes a request over HTTP
        ↓
Browser sends:
Cookie: session_id=...
        ↓
Session cookie travels in plaintext
        ↓
An attacker positioned to observe or intercept
the network traffic can read the credential
        ↓
Attacker obtains the session ID
        ↓
Attacker replays the credential
        ↓
✓ Session hijacked

An attacker capable of observing or modifying the network path might include someone operating a malicious network access point, a compromised network device, or another attacker who has successfully placed themselves in a position to intercept the victim's traffic.

Historically, this was a widespread and practical form of session hijacking. Shared and open Wi-Fi networks were particularly risky because unencrypted HTTP traffic could potentially be observed by other parties on the same network.

The primary defense is straightforward:

Never allow session credentials to travel over unencrypted HTTP.

The application should enforce HTTPS across every endpoint, not merely on the login page. The session cookie should also be marked Secure, which instructs the browser to send that cookie only over HTTPS.

Application uses HTTPS
        +
Session cookie marked Secure
        ↓
Browser refuses to send the session cookie
over an unencrypted HTTP connection
        ↓
Network observers cannot read the cookie
from the encrypted HTTPS traffic
        ↓
✓ Plaintext network interception blocked

The Secure flag provides an important additional safeguard. Even if an application is intended to redirect HTTP traffic to HTTPS, configuration mistakes can occur: a forgotten legacy endpoint, an incomplete redirect rule, or another HTTP-accessible path may remain available.

Without Secure, a browser may send an otherwise valid session cookie when making a request over HTTP if the cookie's other scope rules allow it. With Secure set, the browser refuses to include that cookie in an unencrypted request.

It is therefore not enough to check only that the main login form uses HTTPS.

The entire session lifecycle must remain protected:

Session is created
        ↓
Session is used
        ↓
Session is renewed or rotated
        ↓
Authenticated requests are made
        ↓
Session is invalidated

Every network path that handles the session
        ↓
HTTPS enforced
        +
Session cookie marked Secure

A single HTTP-accessible endpoint can become a weak point if it causes the browser to expose a session credential that would otherwise remain protected.

The principle is simple:

Authentication is not the only sensitive moment. Every request carrying a session credential must be protected.