The five steps towards extension security in company environments

Ostral Guides - The CISO playbook for governing browser extensions

Ostral Guides - The CISO playbook for governing browser extensions

Ostral Guides - The CISO playbook for governing browser extensions

Ostral Guides - The CISO playbook for governing browser extensions

Browser extensions run inside the tab with access to everything an employee opens, they update silently, and they change owners quietly. This series is the path a security leader can follow to bring that surface under control, from first principles to a standing policy.

François-Henri Champagne

In the extension fleets we audit at Ostral, most already carry at least one active malicious extension, plus a long tail of tools nobody approved. That is the problem in one line: extensions are malware you invited in and shadow IT you cannot see. They read everything in the tab, update themselves silently, and stay invisible to your firewall and your endpoint agent. This playbook is how a security team takes that surface back, in four steps. Each part stands on its own, and you do not need a tool to start.


Why a CISO cannot leave this alone

An extension is third-party code with privileged access that updates itself, running on every endpoint you are meant to protect. Left ungoverned, it is two serious problems at once.

  • Malware you invited in. A single hijacked or malicious extension can read everything in the tab: passwords, session cookies, internal documents. It exfiltrates quietly, and your EDR and firewall never see it. A clean tool can turn overnight through a silent update or a change of owner, as The Great Suspender and the Cyberhaven breach both showed.

  • Shadow IT you cannot see. When anyone can install anything, company data flows to third parties you never vetted, with no agreement and no offboarding. Under NIS2 and GDPR that is ungoverned third-party access to regulated data, and it is your name on the audit.

  • A blind spot that grows. Extensions pile up faster than anyone reviews them, and nothing in the standard stack inventories them. Most fleets we audit are already carrying active malware on day one.

Regulating extensions is one of the cheapest large wins in security. It is privileged third-party software, so it deserves the same governance as anything else with that reach. The four steps below are how you get there.


The journey

The four parts follow the order a security leader actually works in: understand the surface, see what you have, assess a single case, then set the rule that holds. You do not need a tool to begin. You need a method, and it is below.


Understand, discover, assess, regulate. One path from a blind spot to a governed surface.


Part 1 · Understand

The most over-privileged app in your company is a browser extension

Before you can govern extensions, you need to know what they are. An extension is resident, privileged code that runs across every page a user opens, after the browser has decrypted it. This part covers the permission model and the two things that make extensions dangerous: silent updates and ownership changes.

  • What "read and change all your data on the websites you visit" really grants.

  • Why an extension you approved once can behave completely differently a month later.

  • Why none of this shows up in your firewall or endpoint tooling.

Read Part 1: The most over-privileged app in your company is a browser extension →


Part 2 · Discover

Find every risky extension hiding in your fleet

You cannot govern what you cannot see. This part is the practical guide to a complete inventory, from one machine by hand to the whole fleet at once. A list is the foundation, but a name and an install count are not a risk picture.

  • Three routes: your MDM, a script pushed everywhere, and the browsers' own admin consoles.

  • Why you track everything by extension ID, never by name.

  • What an inventory tells you, and the one thing it cannot.

Read Part 2: Find every risky extension hiding in your fleet →

Part 3 · Assess

Spot a malicious extension like a senior security engineer

When one extension looks off, you do not need to read its code for hours. Compare what it does with what it asks for. This part is the method we use at Ostral, step by step, ending in a clear allow, replace, or block.

  • Get the permission list, then judge the gap between function and access.

  • Check the publisher, the ownership history, and the update cadence.

  • A worked example: Huiyi, a translator that quietly reroutes your traffic.

Read Part 3: Spot a malicious extension like a senior security engineer →


Part 4 · Regulate

Lock down risky extensions without slowing your team down

This is the destination: turning what you can do by hand into a standing rule. Build an allowlist, block everything else, run a request workflow, and re-check the list as extensions change.

  • How to build the allowlist, the request workflow, and the update review.

  • How to govern the silent update, the moment most compromises happen.

  • How this maps to NIS2 and NIST CSF obligations.

Read Part 4: Lock down risky extensions without slowing your team down →


The thread running through all four

Every part ends at the same limit. The method works by hand; keeping it current does not. Re-checking every extension, on every silent update, across every browser, forever, is where a hijacked update slips through a fleet that was "governed."

If you read one thing first, make it the permission dictionary. Learning to read permissions changes how you see every other step, and it is the skill that pays off the fastest.