A stolen session identifier lets an attacker act as you without your password or MFA code, because the server treats the identifier as proof you already signed in. Cookie flags such as HttpOnly, Secure and SameSite reduce the ways it can be stolen, and server side expiry limits how long a stolen one works.
Myth 1: MFA protects me even after sign-in
Fact: MFA protects the sign-in step. After that, the session identifier is the credential. If an attacker obtains it, the server has no reason to ask again. This is why OWASP recommends regenerating the identifier after login and privilege changes, setting timeouts, and requiring reauthentication after high-risk events. See how long a remote session should last.
Myth 2: Deleting the cookie logs me out safely
Fact: OWASP states that deleting the cookie on the client alone does not stop a stolen identifier from working. The server must invalidate the session. If a tool only clears the cookie on logout, a copied identifier may still be valid. Look for a "sign out of all sessions" option and use it after any suspected exposure.
Myth 3: HttpOnly stops cookie theft
Fact: HttpOnly blocks JavaScript from reading the cookie, which limits theft through cross site scripting. It does not stop other routes. Malware on the device, a compromised browser extension or a proxy on an untrusted network can still capture it. It also does not stop cross site request forgery, as OWASP notes.
Myth 4: Secure and SameSite are the same thing
Fact: they do different jobs.
- Secure sends the cookie only over HTTPS. Without it, a browser can be pushed into sending the identifier over plain HTTP.
- SameSite controls whether the cookie is sent on cross site requests. OWASP suggests explicitly setting Strict, preferred, or Lax, and using None only with Secure. It treats SameSite as defense in depth, not a replacement for CSRF tokens.
OWASP also suggests the __Host- cookie name prefix for session cookies, which requires Secure, no Domain attribute and Path set to a slash.
Myth 5: Putting the token in local storage is safer
Fact: OWASP says not to store session tokens in localStorage or sessionStorage, because any cross site scripting flaw can read them. A cookie with HttpOnly is not readable by scripts.
What to do as a remote worker
You cannot set cookie flags on tools you do not build, but you can limit exposure.
- Keep browsers and extensions updated, and remove extensions you do not use. A malicious extension can read page content and sessions.
- Do not sign in to admin tools on shared or unmanaged devices.
- Prefer tools that bind sign-in to a device or use short sessions.
- Use sign out of all devices after losing a phone or laptop. See our lost phone playbook.
- Treat a copied session link or exported cookie file as a password.
What to do if you build tools
- Set Secure, HttpOnly and an explicit SameSite on session cookies.
- Use a long random identifier from a cryptographically secure generator, and keep session data on the server.
- Set idle and absolute timeouts and enforce them server side.
- Regenerate the identifier after login and privilege changes.
- Send Cache-Control no-store on sensitive responses.
- Log session lifecycle events using a salted hash of the identifier, not the raw value.
Quick check
If someone steals my session cookie, do they need my MFA code?
Not usually. The server accepts the identifier as proof of a completed sign-in. Short sessions, reauthentication on risky actions and server side logout limit the damage.
Does HttpOnly make cookie theft impossible?
No. It blocks script access to the cookie, which helps against cross site scripting. Malware, a rogue extension or a network attacker may still obtain it.
Sources
Last reviewed: 19 October 2026.
