The `cookies` permission explained: what browser extensions can really access in your sessions

Most people glance at an extension's permissions list and focus on the obvious ones — "Read your browsing history," "Access data on all websites." The cookies permission is less dramatic-sounding, so it gets ignored. I've been going through extension manifests for a while now, and this is consistently one of the most underestimated entries on that list.

Extensions that hold the cookies permission can read, write, and delete HTTP cookies for every site they're allowed to access. In practice, that means they can capture your session tokens, monitor your login activity in real time, and — if they're malicious — authenticate as you on any site you've visited. Understanding what this permission actually grants is one of the more useful things you can do for your browser security in 2026.

What the cookies permission actually grants

The cookies permission unlocks the chrome.cookies API. This API gives an extension four core capabilities:

• Read any cookie for any URL the extension has host permissions for
• Write new cookies or overwrite existing ones
• Delete cookies — immediately ending sessions
• Monitor cookie changes in real time via chrome.cookies.onChanged

That last one deserves emphasis. An extension can register a listener that fires every time a cookie is set or modified on any accessible site. So when you log into your email, your bank, or your company's internal tools, an extension with the right permissions can capture that session cookie the moment the server creates it.

The "right permissions" here means the cookies API plus broad host permissions. Which brings us to the actual attack surface.

Why <all_urls> changes everything

The cookies permission alone doesn't grant access to every site — it works in combination with host permissions. The critical pattern to understand is this combination in a manifest:

"permissions": ["cookies"],
"host_permissions": ["<all_urls>"]

An extension with this pairing can read and write cookies for any website you visit. An extension that requests cookies scoped to a specific domain — say, https://mail.google.com/* — is far more limited.

Most users never check which host permissions an extension requests alongside cookies. The Chrome extension permissions dialog doesn't spell out this pairing clearly. You'll see "Read and modify your data on all websites you visit," which covers host permissions, but not a separate explicit warning about cookie access.

When you combine cookies with <all_urls>, you have an extension that can — depending on what it does with that access — harvest session tokens for Gmail, your bank, Slack, GitHub, any HR system your company uses, and anything else you stay logged into.

What a session cookie is and why it's the actual target

When you log into a website, the server creates a session and stores a token in a cookie. That token is how the server recognizes you on every request after that. Your password stays with you; the session token travels with every page load.

If an attacker gets your session token, they don't need your password. They can make authenticated requests to that site as you — read your email, access your files, submit forms, transfer money. This is why session hijacking is such a persistent attack pattern, and why extensions with cookie access are a real risk vector, not a theoretical one.

Researchers have documented multiple cases of browser extensions specifically designed to extract session credentials from enterprise applications — targeting tools like HR platforms and ERP systems where users stay logged in for hours at a time. The permission that makes this possible is cookies, combined with host access to those domains.

Extensions with legitimate reasons to use cookies

Not every extension requesting this permission is malicious. There are real use cases:

Session managers. Extensions that save and restore browsing sessions need to snapshot your cookie state and write it back when you restore. This is entirely legitimate — but it means they're storing your session data locally, which is worth knowing.

Developer tools. Extensions like Cookie-Editor or EditThisCookie exist specifically for inspecting and modifying cookies. If you're a web developer, these are genuinely useful. If you installed one years ago and forgot about it, check whether it's still from the original developer — ownership transfer attacks use exactly this kind of "innocent" tool.

Some authentication-aware tools. Certain productivity extensions detect whether you're logged into specific services and adjust their behavior accordingly. Reading a cookie to check login state is less invasive than reading the cookie contents and exfiltrating them, but the underlying permission is the same.

VPN extensions. Some VPN extensions use cookie access to manage session state or detect when authentication has expired. However, this is also where the category has had documented problems. As reported by Malwarebytes and The Register in late 2025, Urban VPN Proxy — a Chrome extension with over 6 million users and Google's "Featured" badge — was found to be collecting conversations from ChatGPT, Claude, Gemini, and other AI platforms. Urban VPN held extensive page access permissions; its broad data access capabilities enabled surveillance of user sessions across AI tools. As of March 2026, Urban VPN had not publicly addressed the specific data collection findings described in those reports.

The pattern to watch for: an extension whose core function has nothing to do with session management or developer tooling, requesting cookies plus broad host access with no explanation in its privacy policy.

When it's okay vs. when it's a red flag

Probably fine:

• The extension's stated purpose explicitly involves session or cookie management
• Cookie access is scoped to specific domains the extension actually needs
• The extension is from an audited developer with a clear, public privacy policy
• The extension is open source and the cookie handling is visible in the code

Worth investigating:

• A productivity tool — AI writing assistant, shopping helper, grammar checker — requests cookies plus <all_urls> without explaining why
• The extension's privacy policy doesn't mention what it does with cookie data
• The extension recently changed ownership — a known attack pattern where bad actors acquire established extensions to inherit their user base and permissions
• The extension requests cookies but doesn't appear to need any session-aware features

One development worth watching: starting in Chrome 147, Google is shipping Device Bound Session Credentials (DBSC), which ties authentication sessions to specific hardware rather than portable cookies. This will make it harder for attackers who exfiltrate cookies to replay them on a different machine. But DBSC doesn't prevent an extension from reading cookies on-device and using them directly — it's a defense against token theft via network interception or file extraction, not against malicious browser code. If an extension has cookie permission and turns bad, DBSC won't stop it.

How to check which of your extensions have this permission

In Chrome, you can check manually:

1. Open chrome://extensions/
2. Click "Details" on any extension
3. Look at "Permissions" — if you see "Read and modify your data on the websites you visit," check the site access scope (all sites vs. specific sites)

The manual approach is slow if you have more than a handful of extensions. Extenshi's catalog shows every permission an extension holds, including whether it combines cookies with broad host access. You can look up any extension and see exactly what it's scoped to do — and whether the combination of permissions looks reasonable for its stated purpose.

A 2026 study covered by Help Net Security, based on Incogni's analysis of 442 AI-powered Chrome extensions, found that 42% require scripting permissions — a related capability that affects 92 million users. Cookie permissions weren't broken out separately, but scripting and cookies often appear together in extensions that need deep page integration. The study flagged 10 extensions with both high risk likelihood and high risk impact, suggesting the problem isn't confined to obvious malware.

The check you should run now

Audit which extensions have access to your most sensitive sites. The combination to look for is: cookies permission + access to your email, banking, company tools, or any site you use for authentication.

If an extension has that access and you can't explain why it needs it, that's your signal to investigate. Look up the extension in the Chrome Web Store, check when it was last updated, verify the developer hasn't changed, and read through any recent reviews flagging unusual behavior.

Check your permissions →

The cookies permission sounds technical and boring. The data it provides access to — your active sessions on every site you use — is anything but.

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].