IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Session hijacking — stealing the session cookie
Maya signs in once. After that, a small session cookie goes with every request to show it is still her. The cookie is a bearer token: whoever holds it is Maya, with no password. Your goal: name how cookies get stolen and the settings that protect them.
- The server trusts whoever shows the cookie. Copy it and you copy the session.
- HttpOnly, Secure and SameSite protect the cookie. Each one does only part of the job.
- Device binding makes a stolen copy useless on another machine.
- Detect odd sessions, then revoke them.
The cookie is the login
When Maya signs in, the server gives her browser a cookie with a session ID. That is a random string. On the server it points to a record: "this is Maya, signed in at 09:14, MFA passed". Her browser sends the cookie on every click. So she does not type a password on each page.
Here is the catch. The server trusts the cookie because someone showed it. The sender proves nothing. This is the stolen-token problem in a browser (see Sessions, cookies & sign-out).
How a cookie escapes the browser
🩹 Cross-site scripting
XSS means an attacker's script runs on your page. If JavaScript can read the cookie, the script can send it away. The fix: make the cookie invisible to scripts.
🦠 Malware that steals
Infostealer malware on Maya's laptop copies cookies out of the browser. No flag stops malware. But you can make a stolen copy useless on another machine. That is binding.
📜 Leaks in addresses and logs
The wrong person can read a session ID in a web address, a Referer header or a debug log. Keep it in a cookie. Never put it in the address. Never log it.
The hardening checklist
No single trick stops hijacking. You stack cheap, boring settings (the OWASP Session Management Cheat Sheet).
| Control | What it does |
|---|---|
| HttpOnly | JavaScript cannot read the cookie. This defeats cookie theft by XSS. |
| Secure | The cookie travels only over HTTPS. |
| SameSite | Lax or Strict limits when the browser sends the cookie on cross-site requests. It blunts cross-site request forgery. |
| Short life and idle timeout | The session ends soon, and after a quiet period. A stolen copy works for less time. |
| New session ID | Issue a fresh ID at sign-in and on any change of privilege, like step-up. Then a planted ID cannot become a signed-in one. This stops session fixation. |
| Device binding | Tie the session to a key on the device, so a copied cookie fails elsewhere. DBSC does this for browser cookies. |
| Fast revocation | End a session everywhere in seconds. Do it in your own system and, through CAEP & Shared Signals, in every connected app. |
HttpOnly stops a script from reading the cookie. It does not stop the script from acting. Injected script can still send requests from inside Maya's page, as Maya. So HttpOnly never replaces fixing the XSS bug itself.
Bearer or bound
Remember the shoe-stand token in Cookies & sessions? A bearer cookie is that token: the keeper hands over the shoes to anyone who holds it. A bound session (also called sender-constrained) also asks for proof of a key that never leaves Maya's device. So "steal the cookie, become Maya" turns into "steal the cookie, get an error".
Cookie settings protect the cookie. Detection protects the session. Alert on the same session ID from two countries at once, a device or browser change in mid-session, and impossible travel. Then revoke the session and force a fresh, phishing-resistant login. Do not just log it.
An infostealer copies Maya's session cookie. The attacker pastes it in on his own laptop. The session is device-bound, so the server asks for a proof he cannot give, and the request fails. Zara's detection also sees the ID on a new device and sends a CAEP signal. Maya's real session ends everywhere within seconds.
Go deeper: Cookie name prefix
A cookie name that starts with __Host- forces Secure, a path of /, and no Domain setting. Other subdomains cannot overwrite it.
Go deeper: DBSC: status and limits
In browsers, binding is DBSC, Device Bound Session Credentials. The browser makes a key pair in secure hardware, such as a TPM. The key cannot be exported. The server gives out short-lived cookies. It renews them only when the browser signs a challenge with the key. A stolen cookie soon expires and cannot be renewed.
As of October 2026, Chrome on Windows supports DBSC (since Chrome 146, April 2026). macOS support is planned. The standard is a draft in the W3C Web Application Security Working Group.
For OAuth tokens, DPoP or mTLS do the same job (see Stolen-token defenses II).
DBSC is not a cure-all. Malware already on the device can still use the live session. Cross-site sign-in through another provider is still being worked on.
🧪 Interactive lab — enable JavaScript to play with this one.
Grade your own session-cookie flags (HttpOnly, Secure, SameSite and token-response hardening) with Cookie Check. Then confirm that you can end a session on demand with Logout Check.