Extension Monitoring
Browser extensions are one of the most under-governed pieces of the modern attack surface: they run inside the browser with broad permissions, update silently, and are routinely bought and weaponized by malicious actors. The Extensions page gives you a fleet-wide inventory of every third-party extension installed alongside Surface Security, scores each one for risk, tracks install/update/removal events, and — when you are ready — enforces an approved whitelist by automatically disabling everything else.
[SCREENSHOT PLACEHOLDER: The Extension Monitoring page showing the four stat cards (Total Extensions, Whitelisted, Unwhitelisted, High Risk) and the tab bar]
How it works
On each managed browser, the Surface extension periodically inventories the other extensions installed (default every 60 minutes; configurable). For each one it records the name, version, enabled state, install method (store, admin-deployed, developer mode, or sideloaded), and the full set of requested permissions and host permissions. It also reports change events as they happen: installed, uninstalled, updated, enabled, and disabled — version changes matter because a benign extension that changes hands can turn malicious in a single silent update.
From this telemetry the platform maintains an aggregate view per extension across the fleet and computes a risk score from 0 to 100 for each installation:
| Factor | Weight | What it measures |
|---|---|---|
| Permissions | up to 40 | How dangerous the requested permissions are |
| Install Method | up to 15 | Sideloaded and developer-mode installs score higher than store installs |
| Permission Escalation | up to 20 | Whether the extension has gained permissions over time |
| Environment Novelty | up to 15 | How unusual the extension is in your environment |
| Store Presence | up to 10 | Whether the extension is absent from the official store |
Scores map to labels: Low (under 30), Moderate (30-49), Elevated (50-69), High (70-89), and Critical (90+). Permissions considered high-risk include access to all URLs, web request interception, the debugger, proxy control, native messaging, cookies, history, tabs, and clipboard read/write.
An optional heuristic detection layer goes beyond static permissions: it watches web requests to sensitive URLs you define (identity providers, banking, email, and so on) and flags suspicious extension behavior such as header stripping, content injection, redirect manipulation, and cookie tampering, with configurable confidence thresholds.
Enforcement is whitelist-based. When blocking is enabled and confirmed, endpoints disable any extension not on the approved whitelist at their next sync, and re-enable extensions you have marked as Required if a user turns them off.
Using the page
Open Attack Surface > Extensions in the sidebar. Four cards summarize the fleet: Total Extensions (instances, with the unique count), Whitelisted, Unwhitelisted (require review), and High Risk (dangerous permissions). Below them, four tabs organize the work.
Whitelist tab
The list of approved extensions. Add to Whitelist opens a dialog where you enter the extension ID (the 32-character store identifier), a name, and optionally a description, publisher, category, a semver Version Constraint (leave empty to allow any version), a reason for approval, and the Required Extension flag for extensions that must stay installed and enabled for compliance. Each entry can be edited or removed; removing an entry immediately marks that extension as unwhitelisted everywhere it is installed.
Inventory tab
Every extension observed across the fleet, filterable by All / Whitelisted / Unwhitelisted. Columns show the extension name and ID, latest version, install count, device count, user count, Max Risk score badge, status (whitelist state, a High Risk chip where applicable, and how many installs are enabled), and last seen. A Whitelist quick action approves an unwhitelisted extension in place, and clicking an extension name opens its detail page.
[SCREENSHOT PLACEHOLDER: The Inventory tab filtered to Unwhitelisted, showing risk score badges and the Whitelist quick action]
Events tab
A chronological feed of extension lifecycle events fleet-wide: installs, uninstalls, updates (with the old and new version shown), enables, and disables, each marked with the extension's whitelist status at the time and whether the event generated an alert.
Settings tab
All monitoring and enforcement configuration (described below).
The extension detail page
Click any extension in the inventory to open its detail page.
- Header — name and extension ID, plus an Add to Whitelist button if it is not yet approved.
- Stats — total installs, unique users, how many installs are enabled, and device count.
- Whitelist Status — approval state, and for whitelisted extensions the category, the recorded reason, and when it was added.
- Permissions — every requested permission and host permission as chips, with high-risk ones highlighted and counted.
- Risk Score — the maximum and average score across installs, with a factor-by- factor breakdown (Permissions, Install Method, Permission Escalation, Environment Novelty, Store Presence) shown as progress bars.
- Installations by Version — each version present in the fleet and, under it, every device carrying it: the user's name and email, an install-type badge (Admin, Store, Dev, Sideload, Other), the per-install risk score, a Disabled chip where applicable, browser and OS, and last seen. Each entry links to the device's page. A version filter narrows the list when multiple versions are in circulation.
[SCREENSHOT PLACEHOLDER: Extension detail page showing the Permissions chips with high-risk highlights and the Risk Score breakdown bars]
Alerts
With monitoring enabled, the Settings tab lets you generate alerts for four conditions, which appear in the standard alert queue (see Alerts):
- Unwhitelisted extension — an extension outside the approved list was observed.
- Extension version change — an installed extension updated (a key supply-chain signal).
- High-risk permissions — an extension requests dangerous permissions.
- High risk score — an installation's computed risk score is high.
Configuration
All settings live on the Settings tab.
- Enable Extension Monitoring — the master switch; collects and analyzes extension data from managed endpoints.
- Block unwhitelisted extensions — turns on enforcement. Because this changes user browsers, it requires an explicit confirmation showing exactly how many unwhitelisted extensions across how many devices will be disabled at the next sync cycle. Enforcement is not active until confirmed.
- Alert toggles — the four alert conditions above, individually switchable.
- Scan interval (minutes) — how often endpoints re-inventory their extensions (default 60, minimum 5).
- Heuristic Detection — requires monitoring to be enabled. Configure the Sensitive URL Patterns to watch (a default list covering major identity providers, cloud portals, banking, and email is provided; add your own patterns or reset to defaults), and three Confidence Thresholds: Low (report only), Medium (notify the user), and High (eligible for auto-disable). Optionally enable Auto-disable high-confidence threats with a minimum attribution confidence (0-100) so only firmly attributed extensions are ever disabled automatically.
A sensible rollout order: enable monitoring and alerts first, build the whitelist from the Inventory tab while enforcement is off, then enable blocking once the whitelist covers your legitimate footprint.
Worked example: a sideloaded extension with critical risk
The High Risk card shows 1. In the Inventory tab, an unfamiliar "PDF Toolkit" extension shows a Max Risk of 92 (Critical) on a single device. The detail page tells the story: permissions include access to all URLs, web request interception, and cookie access (three high-risk chips); the risk breakdown shows near-maximum scores for Permissions and Install Method; and the single installation carries a Sideload badge — it never came from the store. The device entry names the user and links to their device page.
The administrator contacts the user, who installed it from a download site to merge PDFs. The extension is removed, and the team enables Block unwhitelisted extensions after confirming the whitelist covers the 12 legitimate extensions in the fleet. From then on, any repeat of this pattern is disabled automatically at the next sync and surfaced as an alert instead of a discovery.
FAQ
Does this monitor what pages users visit? No. Extension monitoring inventories installed extensions and their properties. The optional heuristic layer observes extension behavior only on the sensitive URL patterns you configure.
What happens when I remove an extension from the whitelist? It is immediately treated as unwhitelisted on every device that has it. If blocking is enabled and confirmed, it will be disabled at each endpoint's next sync.
What does the Required flag do? Required extensions are treated as mandatory: if a user disables one, the endpoint re-enables it.
Why do install and enabled counts differ? Users can disable an extension without uninstalling it; the inventory tracks both states, and the status column shows how many installs are currently enabled.
Can a whitelisted extension still raise alerts? Yes — version-change, high-risk permission, and risk-score alerts apply regardless of whitelist status, so a trusted extension that suddenly changes behavior still gets your attention.
How does this relate to the rest of the attack surface? Extensions are the browser-resident half of the picture; the web applications employees reach are covered by Attack Surface Discovery and Credentials.