SECURITY
Can someone steal your cookies?
Understand session hijacking, how stolen sign-in cookies can expose an account, and what to do if you suspect cookie theft.
The short answer
Yes. If an attacker copies a valid sign-in cookie, some websites may accept it as proof that the attacker is already logged in. This is session hijacking. The cookie is not a virus; it is a credential that can be misused.
Why a sign-in cookie is valuable
After you log in, a website needs a way to recognize later requests without asking for your password on every page. A session identifier can serve that role. Someone who obtains a usable identifier may be able to act through the existing session until it expires or is revoked.
Not every cookie grants account access: a language preference is different from an authentication token. The impact depends on what the website accepts and which actions need additional verification. OWASP explains session hijacking.
How cookies can be exposed
- Malicious code in a vulnerable page: a cross-site scripting flaw can expose cookies that are accessible to scripts.
- Insecure transport: a sensitive cookie sent over unencrypted HTTP may be intercepted.
- Compromised devices: malware or other unauthorized access can put browser data and account sessions at risk.
Cookie theft is one reason to treat a suspicious download or unexpected browser extension as an account-security issue, not merely a nuisance. OWASP’s attack overview describes common session compromise routes.
Reduce your risk
Keep the browser and operating system updated. Remove extensions you do not need, avoid untrusted software, and review security alerts instead of dismissing them. Google’s compromised-account guidance includes device and software checks.
Use multifactor authentication where available. It remains valuable, but an already authenticated session can sometimes be abused without a fresh password or second-factor prompt. A website can require additional verification for sensitive actions; do not assume every service does.
Sign out when you finish on a shared device. A properly implemented sign-out invalidates the session on the server. Simply shutting a tab, or deleting a local cookie, is not a substitute for server-side revocation. See OWASP’s session-management guidance.
What to do if you suspect cookie theft
- Use a device you trust. If your current device may be infected, avoid entering new credentials on it.
- Open the service directly. Review recent security events and signed-in devices. Do not use a link from a suspicious alert.
- End unfamiliar sessions. Use “sign out all devices” or the service’s session-revocation controls where available.
- Secure the account. Change the password, review recovery details, and enable or review multifactor authentication.
- Check for persistence. Review connected apps and unexpected account changes; for email, check forwarding and filters.
- Address the device problem. Remove suspicious software and follow the provider’s recovery guidance before resuming sensitive activity.
These steps adapt Google’s account-recovery checklist; other services have different controls. If you cannot regain access, use the provider’s official recovery process.
What websites should do
Secure restricts cookie transmission to HTTPS, with a localhost exception. HttpOnly prevents page scripts from reading a cookie. SameSite controls when cookies accompany cross-site requests. These controls reduce specific risks; they do not fix an infected device or every website vulnerability. MDN documents these attributes.
Sites also need session expiration, revocation, identifier rotation after authentication, and appropriate checks for sensitive actions. These are server responsibilities, described in OWASP’s session-management guidance.
For everyday privacy rather than account compromise, continue with first-party and third-party cookies. For storage duration, read session vs. persistent cookies.