A browser extension looks harmless. A color picker here, a grammar checker there. But it is software running inside the browser with far more reach than most people realize, and it is a favourite way in for malware and a quiet source of shadow IT. At Ostral we find active malicious extensions in most of the fleets we audit. This guide shows how extensions work, and why that reach makes them worth regulating.
An extension is code that runs inside the browser
An extension is a packaged bundle of HTML, CSS, and JavaScript that the browser installs and runs alongside the pages a user visits. It is not a website the user navigates to. It is resident software, loaded every time the browser starts, that can observe and act on the pages opening in front of it.
A website only sees its own domain. An extension can see and change every site the user opens, from your payroll portal to your webmail. It works from inside the user's own session, after the browser has decrypted the page.
The permission model: what an install actually grants
When an extension is installed, it declares the permissions it wants, and the browser shows a short warning. Most people click straight through. That warning is worth reading, because its most common line reads almost word for word like this:
Read and change all your data on the websites you visit.
That one line lets the extension read anything on the page and change what it does. It can capture what a user types, including passwords and private messages, rewrite links, and move data off the page. A useful tool and a data-theft payload ask for it in the exact same words.
Permissions fall into a few broad groups:
Host permissions decide which sites the extension can touch.
<all_urls>means every site; a narrow declaration means only a named domain.API permissions unlock browser capabilities such as reading tabs, capturing audio, changing proxy settings, accessing cookies, or rewriting network requests.
Optional permissions can be requested later, at runtime, after the install warning is long forgotten.
For every permission an extension can request, and what each one grants, see the permission dictionary.
Why extensions change after you approve them
Security reviews almost always miss this. An extension is not static. It updates itself silently, with no prompt, and the version you approved can behave completely differently a month later.
Two mechanisms make this dangerous:
Silent auto-update. The browser pulls new versions from the store without asking. The user who approved version 1.2 never sees version 1.9 arrive.
Server-driven behavior. The service worker can fetch configuration or instructions from a remote server. The published code can stay the same while the actual behavior is switched on remotely. A real case: a remote proxy configuration file that an attacker can change at any time, rerouting traffic with no visible update at all.
Ownership adds a third path. Extensions get sold, and a trusted tool with a big install base is a valuable asset. The Great Suspender, a tab manager with millions of users, was handed to an unknown owner in 2020, quietly turned malicious, and was pulled by Google.
Why this matters for a security team
Add it up. An extension works from inside the user's session, can reach every site, and can change what it does at any time. Your firewall sees none of it, and your endpoint agent just sees a browser being a browser.
An extension is not something you approve once and forget. It is resident, privileged code that keeps updating itself. The only control that lasts is watching what each one does over time, long after install.
The rest of the series puts that into practice: Part 2 covers listing every extension running across your fleet, and Part 3 covers examining a single extension when something looks off.
