activeTab permission explained: the host access that skips Chrome's warning

Most permission warnings in Chrome are loud. You add an extension, a dialog pops up, and it tells you the thing can "read and change all your data on all websites." Scary, and at least honest.

activeTab is the opposite. It's the permission that lets an extension reach into the page you're looking at — and it shows you no warning at all. No dialog, no list, nothing. Install the extension and that's it.

That silence isn't a trick. It's by design, and it's actually the good kind of host access. But "no warning" and "no access" are very different things, and the gap between them is worth understanding before you assume an extension is harmless just because Chrome stayed quiet.

It's also extremely common. Across the 308,000 live listings in the Extenshi catalog, activeTab is the second-most-requested permission — declared by 108,948 extensions, about 35% of everything in the stores. So this isn't an edge case. It's probably on extensions you're running right now.

What activeTab actually is

activeTab lives in the permissions array of an extension's manifest.json:

{
  "permissions": ["activeTab", "scripting"]
}

The plain-language version: "Let me touch the current tab, but only when the user asks me to."

That "only when asked" part is the whole point. Unlike broad host_permissions, activeTab grants nothing on its own. The extension gets access only after you invoke it — clicking its toolbar icon, picking its context-menu item, or hitting its keyboard shortcut. No click, no access.

And the access it hands over is narrow. It applies to the one tab that was active when you invoked the extension. Not your other tabs, not background tabs, not the next page you open. Just the page in front of you, at the moment you reached for the tool.

What it actually allows

When you do invoke it, activeTab is more capable than its quiet reputation suggests. For that one tab, the extension gets a temporary grant that includes:

Reading the page. Paired with the scripting permission, the extension can inject JavaScript into the active tab and read the DOM — form fields, page text, whatever is rendered. I broke down what that injection can reach in my piece on the scripting permission.

The sensitive tab properties. Normally an extension needs the broader tabs permission to read a tab's full URL, title, and favicon. With activeTab, it gets those for the active tab without the extra permission. That distinction matters — I covered the difference in my post on the tabs permission.

Modifying what you see. It can inject CSS and change the page's appearance or content, not just read it.

So the moment you click a screenshot tool's icon on your banking dashboard, that extension can — for that instant — read everything the page is showing, including an account number sitting in the DOM. The gesture is the consent. It's just invisible consent.

How long the access lasts

This is the part people get wrong. The grant isn't a single snapshot.

Once you invoke an extension on a page, its activeTab access stays alive until you navigate that tab to a different origin or close it. Same-origin navigation keeps it. Click the tool once on mail.google.com, then move between folders and messages inside Gmail, and the extension's access rides along the whole time, because you never left the origin.

Leave for another site, and the grant is dropped. Come back later, and the extension has to wait for another click. That's a real, enforced boundary — but it's wider than "one page, one moment."

When it's fine — and when to pause

Here's the good news, because there's a lot of it. activeTab is the least-privilege way to build an extension that acts on the page you're viewing. A color picker, a QR generator, a "summarize this article" button, a screenshot tool — none of these need to watch every site you visit.

They need the current page, when you ask. activeTab plus scripting is exactly right, and it's why those tools install with no warning.

When I audit an extension, seeing activeTab instead of broad host permissions is a green flag. The developer chose the scoped option.

The thing to watch for is activeTab declared alongside <all_urls> or other broad host_permissions. When both are present, the broad grant wins and activeTab becomes meaningless — the extension already has standing access to everything, click or no click. If a listing's privacy pitch leans on "we only use activeTab" but the manifest also asks for all sites, that story is hollow. The contrast with full host access is something I dug into in my host permissions explainer.

The other mismatch worth noticing: an extension that requests activeTab but has no button, shortcut, or menu item — nothing you'd ever click to trigger it. The permission only makes sense for gesture-driven features. Its presence without a gesture is a small "why?" worth asking.

And the honest caveat: activeTab limits scope and timing, not intent. A malicious extension can still scrape and exfiltrate whatever the page shows the instant you click it. The permission narrows the window; it doesn't vet what happens inside it.

How to check your own extensions

You don't need to read any code to get a feel for this:

1. Open chrome://extensions and click "Details" on an extension. Under "Site access," an activeTab-style extension typically shows access only "On click" rather than "On all sites." That's the scoped behavior in action.

2. Compare the request to the feature. If the extension's whole job is "do something when I click it," activeTab fits. If it claims that but also has access to all sites, the scoping is on paper only.

3. Restrict where you can. For many extensions Chrome lets you switch site access to "Only when you click" from the Details page — pushing them toward the activeTab model even if they asked for more.

4. Search the Extenshi catalog for anything you're unsure about. The scan lays out declared permissions next to the extension's category, so you can see whether activeTab is doing the privacy work the listing claims — or whether a broad host grant is quietly sitting next to it.

Common questions about activeTab

What is the activeTab permission, in one line? It's a host-access permission that lets an extension touch the current tab — but only after you click its icon, shortcut, or menu item, and only until you leave that origin. No click, no access.

Does activeTab work in Firefox the same way? Mostly, yes. Firefox supports activeTab with the same click-to-grant model, so a cross-browser extension can lean on it in both stores. The edges differ a little, but the core promise — access on gesture, scoped to the active tab — holds in Chrome, Edge, and Firefox alike.

What does "missing activeTab permission" mean? That's a developer-side error, not a user one. It shows up when an extension's code calls an API that needs the active-tab grant — like chrome.scripting.executeScript on the current tab — but the manifest never declared activeTab (or the user hasn't clicked yet, so the grant isn't live). The fix is to add activeTab to the permissions array and trigger the feature with a real user gesture.

activeTab or the scripting permission — which do I need? Usually both, and they do different jobs. activeTab says when and where you're allowed in (this tab, after a click). scripting is the API you call to actually inject code once you're there. Paired, they're the least-privilege way to read or change the page on demand.

activeTab is one of the better things in the extension permission model. It's the version of host access that respects "only when I ask." But quiet isn't the same as harmless — knowing what that one click actually hands over is how you tell a well-behaved tool from one that's just good at staying out of the dialog box.

Check your permissions now →

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].