The `scripting` permission explained: what browser extensions can really inject into your pages

Picture this: you're on a Zoom call with your whole company. An extension you installed months ago is quietly running in the tab. It reads the meeting URL, scrapes the participant list, captures speaker bios and company affiliations, then sends all of it to a remote server in real time.

You never clicked anything. The extension worked fine for its stated purpose. Nothing seemed wrong.

That's not a theoretical scenario. In early 2026, BleepingComputer reported that 18 browser extensions across Chrome, Firefox, and Edge were doing exactly this to 2.2 million users. The extensions targeted 28 conferencing platforms — Zoom, Microsoft Teams, Google Meet, Cisco WebEx — and they all shared one permission that made it possible: scripting.

What the scripting permission actually is

When an extension requests the scripting permission, Chrome doesn't always surface it in a way that makes you think twice. It shows up in the permission dialog bundled with other things, and the name sounds technical rather than alarming.

Here's what it actually means: the scripting permission lets an extension run its own JavaScript on web pages you visit.

JavaScript is what web pages are built from. When an extension can inject its own script into a page, it has access to everything JavaScript on that page can reach. That's a very large surface area.

In Manifest V3, the scripting permission consolidated what previously required a mix of the tabs permission and content script declarations. It's now the standard way extensions interact with page content programmatically — which means it shows up in a huge range of extensions, from useful to dangerous.

What it actually lets extensions do

The scripting permission alone doesn't do anything — it needs to be paired with host permissions telling the browser which pages the extension is allowed to touch. An extension with scripting + <all_urls> gets access to every site. One with scripting + https://zoom.us/* gets Zoom specifically.

Once that access is in place, here's what the injected code can reach:

Everything visible on the page. The DOM — every element, every text node, every form field. Emails in Gmail. Meeting details in Zoom. Account balances in banking apps. If you can see it in your browser, an injected script can read it.

Keystrokes and input events. A script injected into a login page can capture your username and password character by character as you type, before the page's own code does anything with them.

Page modifications. This is how legitimate extensions work — password managers fill in credentials, translation extensions replace text, grammar tools rewrite sentences. But it's also how attackers redirect you to lookalike pages or silently swap payment details.

Session data the page exposes. Depending on how a site is built, injected code can access localStorage, sessionStorage, and cookies not marked as HttpOnly. For some sites, that's session tokens — meaning an active authenticated session.

Network requests from the page. Scripts can wrap fetch() and XMLHttpRequest() to intercept data going in and out: API tokens, form submissions, authentication headers.

Real-world examples, good and bad

The vast majority of extensions using scripting are doing something legitimate. Grammarly needs it to check your writing. Password managers use it to fill credentials. Google Translate uses it to swap text. These extensions have the permission because their core feature requires it.

The Zoom Stealer campaign illustrates what the other end looks like. According to BleepingComputer's coverage, 18 extensions — including one called "Chrome Audio Capture" with over 800,000 installs — used their access to conferencing pages to harvest corporate intelligence via persistent WebSocket connections. The exfiltrated data included meeting URLs with embedded passwords, participant names, job titles, company affiliations, and scheduled times.

It was exfiltrated in real time to servers behind domains like zoomcorder.com. BleepingComputer reported the infrastructure was hosted in China; as of publication in March 2026, the extension publishers had not publicly responded to these findings. I broke down what conferencing extensions can actually see in your meetings separately — the scripting permission is the mechanism that made it possible.

What makes this case study useful for understanding the permission: the extensions were functional. They delivered real value, earned genuine positive reviews, and showed no visible red flags during normal use. The data harvesting only kicked in when a user navigated to a conferencing page — which is exactly what the scripting + targeted host permission combination was designed for.

You can look up permissions for any extension you're considering installing on the Extenshi catalog.

When to worry vs. when to shrug

A few things I look at when evaluating an extension with the scripting permission:

Probably fine if:

• The core feature obviously requires page interaction (translation, grammar, password fill, annotation)
• Host permissions match the stated feature — a Zoom productivity extension that only claims zoom.us/* makes sense
• The extension has years of reviews, a known developer, and hasn't changed owners recently

Worth a closer look if:

• The extension claims scripting + <all_urls> but only does something on one or two specific sites. There's no legitimate reason a Zoom companion tool needs access to your banking site.
• The extension was installed via a direct link rather than Chrome Web Store search. The Secure Annex research published in March 2026 identified 35 extensions with 6 million installs that were deliberately delisted from search results — meaning they spread through direct links specifically to avoid organic discovery.
• The extension is recent, has sparse reviews, or recently transferred ownership.

Actively concerning if:

• scripting + <all_urls> + cookies + webRequest appear together in a small, obscure extension. That combination covers pretty much the entire browser session.
• Any of those permissions appear in an extension that doesn't clearly need them for its stated purpose.

The combination of permissions matters more than any single one. An extension with scripting and a single-site host permission has limited blast radius. The same extension with <all_urls> can touch everything.

How to check what you have installed

In Chrome:

1. Go to chrome://extensions/
2. Click Details on any extension
3. Scroll to Permissions — you'll see what it declared

That gives you the list. What it doesn't tell you is whether the combination of permissions is actually risky. An extension with five permissions might be benign; an extension with two might be high-risk depending on which two.

The Extenshi catalog shows permission breakdowns for extensions and aggregates permission combinations into a risk score — so you can see at a glance whether scripting is paired with something worth worrying about, rather than evaluating each permission in isolation.

The Extenshi permissions scanner can flag extensions you already have installed that combine scripting with broad host access, so you're not manually auditing one extension at a time.

The short version

The scripting permission isn't a red flag on its own — it's how most useful extensions work. But paired with <all_urls>, it gives an extension a very large window into your browser session. The key question is: does this extension actually need to touch every website I visit, or just the one thing it claims to do?

If the answer doesn't match the permissions, that's the right reason to pause before keeping it installed.

FAQ

Is the scripting permission dangerous?

Not by itself. It's how password managers, translators, and grammar tools do their job. The risk comes from what it's paired with: scripting plus a narrow host permission has a small blast radius, while scripting plus <all_urls> lets an extension read and modify every page you open. Judge the combination, not the single permission.

What can an extension do with the scripting permission?

Run its own JavaScript on the pages its host permissions allow. That means reading the full DOM (form fields, emails, account balances), capturing keystrokes, modifying the page, reading non-HttpOnly cookies and localStorage, and intercepting the page's own network requests. Anything JavaScript on that page can reach, the injected script can reach too.

What's the difference between scripting and activeTab?

activeTab grants temporary access only to the current tab, and only after you click the extension's icon — access disappears when you navigate away. scripting combined with declared host permissions is persistent and doesn't need a click. A tool that only acts when you invoke it should prefer activeTab; standing scripting + <all_urls> on a single-purpose extension is the mismatch worth questioning.

Check your extensions for high-risk permission combinations →

---

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