Browser extensions are an enterprise control problem, not a user hygiene problem
A modern enterprise browser stopped being a thin client for the web some time ago. It holds session cookies for every SaaS application the business runs on, and it can reach data that the network security stack never sees. Extensions sit inside that boundary with broad permissions, and most organisations manage them with an ad-hoc approval chat and a blocklist that is always behind.
Why the extension surface is different
In 2025, LayerX reported that 99 percent of enterprise users had at least one browser extension installed, 53 percent had more than ten, and 53 percent of installed extensions carried high or critical permissions. More than 20 percent of enterprise users had installed a generative AI extension. Those tools reach sensitive data permissions at roughly twice the rate of other extensions and routinely route corporate content to third-party services outside any sanctioned AI programme.
The structural difficulty is visibility. Network gateways, secure web proxies and endpoint agents see encrypted traffic and process activity. None of them sees which extension holds permission to read and modify every page the user visits. Research published as Browser Security Posture Analysis makes the same point from the assessment side: extension interference and policy enforcement happen in a space that network or OS level tooling cannot observe directly.
What the enterprise policy engine actually gives you
Chrome and Chromium-based browsers expose extension control through platform policy rather than through user settings. Chrome Enterprise documents three capabilities that matter operationally: a customised extension catalogue that can feature or restrict specific items, centralised extension security and management for requests and permissions, and browser reporting that covers installed applications and versions.
The important detail is precedence. When enterprise policy fixes a setting, an extension that tries to change the same setting receives a control level of not_controllable from the chrome.privacy API. Where a different extension already holds the setting, the value reads controlled_by_other_extensions. The API documentation is explicit that a set call still succeeds and is then immediately overridden, which is why a warning to the user is the recommended pattern. For a security team this matters in two directions: policy beats extensions, and extensions beat each other.
Build the control in four parts
Define the allowlist rather than the denylist. A blocklist requires the team to learn about a malicious extension before it is installed. An allowlist inverts the burden, and the review concentrates on a small set of items that someone has read.
Review permissions against function. An extension that requests cookie access, all-site host permissions and the ability to modify request headers is a credential-interception tool regardless of what its description says. The documented LayerX permission distribution suggests a large share of installs would fail that test.
Force the removal path. Silent installation through policy is a legitimate capability and is also the mechanism used to deploy compliance extensions that collect browser signals. If an organisation can push an extension silently, it must be able to retract one silently, and prove the removal happened per device rather than per report.
Instrument for what you did not anticipate. Browser telemetry should record extension identifiers, versions, permission grants and change events over time. A weekly inventory that shows a new high-permission extension appearing on forty endpoints is the detection that a blocklist would have produced a week late.
Limitations
Nothing here is a complete control. Policy coverage depends on the browser build and on whether the device is enrolled; unmanaged personal browsers on unmanaged devices remain outside it. Permission review is a point-in-time judgement, and an extension author can ship an update that requests more than the reviewed version. Automated browser extensions can also defeat some flow-based detections, and a policy that blocks everything breaks legitimate workflows, which is how exceptions are born.
A second limitation is organisational. Extension review typically falls between the endpoint team, the identity team and the application owners. If nobody owns the allowlist, the practical default is that every user owns it.
Defensive implications
The workable sequence is to inventory first, then classify by permission rather than by popularity, then enforce an allowlist through platform policy with a documented exception process, then monitor for drift. Treat generative AI extensions as a data-handling question rather than a browser question, because the risk is the destination of the content, not the extension itself. Test the policy engine on a sample of real devices. A control that exists in documentation but not on a managed endpoint is a planning artefact.
References
- Chrome Extensions privacy API reference: https://developer.chrome.com/docs/extensions/reference/api/privacy
- Chrome Enterprise management capabilities: https://chromeenterprise.google/download/
- Enterprise Chrome extension strategy summary: https://blog.csdn.net/2601_95807009/article/details/162332393
- Unchecked browser extensions analysis: https://layerxsecurity.com/learn/browser-extension/unchecked-browser-extensions/
- Browser Security Posture Analysis framework: https://arxiv.org/html/2505.08050v1
- Browser signal detection configuration: https://learn.microsoft.com/en-us/purview/insider-risk-management-browser-support
