Session hijacking and cookie theft
Session hijacking uses a valid session credential to act as its owner without completing the original login again.
What it means
Session hijacking uses a valid session credential to act as its owner without completing the original login again. The credential may be stolen through malware, browser compromise, or other exposure. Strong authentication helps protect login but does not automatically invalidate an already-stolen authenticated session.
A practical example
A service sees a session suddenly used in a materially different context. It evaluates the signal with other evidence, challenges or terminates access under its policy, and helps the user revoke sessions while investigating the source of the theft.
What to check
Protect session storage and transport, plan revocation, and monitor meaningful context changes. Use risk signals carefully because shared networks, travel, and device changes can produce legitimate variation.
A common pitfall
An IP address change alone is not proof of hijacking. Overly rigid binding may harm real users, while treating every valid cookie as trustworthy can miss compromise.
Think it through
Why investigate a valid session after a suspicious context change?
Answer: The session may be genuine but held by the wrong person; validity of the credential is not proof of rightful control.
A valid credential may have a different holder
A fictional design agency uses strong sign-in for its document portal. A compromised endpoint later exposes an active session. The attacker may use that session without repeating the original authentication ceremony. This separates the strength of the login method from the continuing protection of the credential issued afterward.
Investigators should reconstruct the session's lifecycle: when it was created, which account and device context were associated with it, when suspicious activity began, and which actions occurred. Avoid placing raw session tokens in ordinary tickets or reports, because evidence handling can create another exposure. Record suitable identifiers or protected references instead.
Context signals are imperfect. A new network address may reflect travel or a mobile network, while an attacker using a nearby network may look ordinary. Combine signals with activity such as unusual exports, settings changes, or unexpected session renewal. The response should match the evidence and business risk rather than relying on a single location rule.
Plan containment before an incident
For the agency example, describe how a user or administrator revokes one session, all sessions, and any linked refresh capability. Determine how quickly each application component observes revocation and what happens to already-open connections. Test those expectations using designated accounts and dummy documents.
Containment should also address the source of theft. Reissuing sessions on an endpoint that remains compromised may simply expose the replacements. Review device security, browser extensions, and credential storage as appropriate to the evidence. A successful recovery restores rightful control and reduces the chance of immediate recurrence; it is more than asking the user to sign in again.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Cookie Theft Mitigation