Browser extension permissions: what they really expose

Why does the permission list matter so much?

Every browser extension runs with privileges the page itself does not have. Where a normal web page is confined to its own origin, an extension can be granted the ability to read and modify other sites, watch network requests, and reach session tokens. The manifest declares which of these powers the extension wants, and the browser grants them at install time.

That declared list is the single most useful signal a non-developer has. It tells you the maximum reach the code can ever have. If an extension that only highlights text on a page asks for access to every site, your cookies, and your network requests, the request does not match the function. Most users click through the install prompt without reading it, which is exactly why browser extension security starts with understanding what each permission grants and ends with checking whether the grant is justified.

Permissions are not malicious on their own. A password manager legitimately needs to read fields on every site. The question is never just "what does it ask for" but "does the behaviour match the request, and what would this reach if the code turned hostile through an update."

What do tabs and host permissions actually grant?

The tabs permission and host access are where most users underestimate the exposure. Host permissions are declared as match patterns such as https://example.com/* for a single site, or the broad <all_urls> and *://*/* patterns that cover every page you visit.

• A specific host pattern limits the extension to one site or a small set. This is the safest shape and what most honest single-purpose tools should request.
• <all_urls> or *://*/* grants the extension the right to inject code and read content on every site, including your bank, your email, and your company tools. This is the broadest grant available and the one to scrutinise hardest.

Host access does not just mean "see the URL." Combined with content scripts, it means the extension can read the rendered page, including form values, displayed account data, and anything in the DOM. The tabs permission additionally exposes tab titles and URLs across the browser, which is enough to profile every site a user opens. When a tool with no cross-site function requests <all_urls>, treat it as a finding, not a convenience.

Which permissions are the high-risk tier?

A practical way to read a manifest is to sort permissions into risk tiers. The capabilities below sit at the top because each one, especially in combination, enables a known abuse class.

• cookies reads and writes cookies for granted hosts. With broad host access this reaches session and authentication cookies, which is the raw material for session hijacking.
• scripting (and the older executeScript) injects arbitrary code into pages. Paired with broad host access, an extension can run its own JavaScript on any site you load.
• webRequest and declarativeNetRequest observe and modify network traffic. These power ad blockers legitimately, but the same hooks can read request headers, including authorization tokens, or redirect requests.
• nativeMessaging lets the extension talk to a separately installed native binary on the machine, bridging the browser sandbox to the operating system.
• debugger attaches the Chrome DevTools protocol to tabs. This is close to total control of a page and has almost no legitimate use in a consumer extension.
• management can read and toggle other installed extensions, which malware uses to disable security tools or competitors.

Lower-risk permissions exist too, such as storage, alarms, or notifications, which rarely expose user data on their own. Sorting this way turns a flat list into a quick judgement: how many top-tier capabilities does this tool hold, and why. Our static analysis applies the same tiering automatically across thousands of extensions.

How are these permissions abused in practice?

The permission-to-abuse mapping is direct, which is what makes the manifest such a strong predictor. A few well-documented patterns recur across malicious and compromised extensions:

• Cookie and session theft. With cookies plus broad host access, an extension reads authentication cookies and forwards them to an attacker server. The victim's logged-in sessions are then replayed without ever needing the password, bypassing many login defences.
• Page injection and credential capture. With scripting and host access, the extension injects code into login or checkout pages to scrape what you type, overlay fake prompts, or alter displayed content such as a wallet address.
• Request tampering. With webRequest, headers carrying tokens can be read, and traffic can be redirected toward attacker infrastructure or affiliate-fraud destinations.
• Sandbox escape. With nativeMessaging, an otherwise web-bound extension reaches a local helper process, expanding the attack from the browser to the host.

These map cleanly onto adversary techniques catalogued in MITRE ATT&CK, such as stealing web session cookies. The most dangerous real-world cases are not extensions that arrive malicious, but trusted tools that turn hostile through an update, which is why version diffing matters as much as the initial review. A catalogue of known-bad cases lives in our malicious DB.

Why is the combination more dangerous than any single permission?

Single permissions are usually defensible. The real risk lives in combinations, because a combination is what completes an attack chain. Cookies alone is limited; cookies plus <all_urls> plus a network sink is a session-exfiltration pipeline. Scripting alone is a developer convenience; scripting plus host access plus webRequest is full page-and-traffic control.

This is why a meaningful review never grades permissions in isolation. It looks for dangerous pairings: broad host access with cookie or scripting access, request interception with credential-shaped data flows, or any consumer tool holding debugger or nativeMessaging. A finding here should always carry evidence, not just a score, so you can see which file uses the capability and how. That evidence-first principle is described in our methodology, and the specific pairings are encoded in our detection rules.

How does Extuno map requested versus used permissions?

A permission list tells you the maximum reach. It does not tell you whether the code actually exercises that reach, and the gap between the two is one of the strongest signals available. An extension that requests debugger but never calls the debugger API is over-privileged at best and staging capability at worst. An extension that quietly uses a capability it barely advertises deserves a closer look.

Extuno resolves this by comparing the declared manifest against what the code does. Static analysis reads every script to see which permitted APIs are actually invoked and where, so we can flag both unused dangerous grants and dangerous combinations that the code genuinely uses. The dynamic sandbox then runs the extension in a network-segmented microVM to observe live behaviour, capturing the actual requests, cookie reads, and injected code rather than relying on the declaration. Where an extension also ships hardcoded credentials, our secret leak detection surfaces those too. The output is a per-permission verdict backed by evidence: requested, used, and how.

How should you read a permission list before installing?

You can apply a usable checklist in under a minute, before you ever click install:

• Match function to reach. Does a single-purpose tool ask for access to every site? If the scope is broader than the job, stop.
• Count the top-tier permissions. Cookies, scripting, webRequest, nativeMessaging, debugger, and management are the ones to weigh. One justified grant is normal; several unexplained grants is a pattern.
• Watch the combinations. Broad host access together with cookies or scripting is the highest-value target for an attacker.
• Remember updates change the picture. A tool you trust today can request more, or behave worse, after an update. Re-checking matters as much as the first review.

The same discipline applies well beyond browsers. Developer ecosystems carry equivalent over-privilege and update-channel risks, covered in our work on supply chain security and package security. Permissions are simply where the browser makes the blast radius visible, which is a gift if you read it.

Sources

• Chrome Developers: Declare permissions
• MDN Web Docs: Extension permissions
• MITRE ATT&CK: Steal Web Session Cookie (T1539)
• OWASP Top 10
• Chrome Web Store program policies

Related