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 tabs 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; the extension publishers have not publicly responded to these findings.

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.

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