Permission Creep in the Toolbar: A Control Model for Browser Extensions

In most UK organisations, the software estate is counted, licensed and periodically reviewed. The browser extension estate is not. Extensions are installed against a user profile rather than a device image, updated silently from a store, and often synchronised through a personal account. They sit beneath the line of sight of software asset management, and frequently beneath endpoint management as well. Yet an extension with content-script access to an authenticated HR portal, finance system or patient record interface can read and alter what the user sees, and can act with the user's session privileges.

That does not make extensions inherently suspect. Password managers, accessibility aids, translation tools and research utilities can be genuinely useful. The governance question is not whether an extension is likeable but what it can reach, who publishes it and whether the organisation has knowingly accepted the access.

Why conventional controls miss the toolbar

Software asset management typically reconciles installed applications, licences and servers. Extensions do not arrive as MSI packages, do not appear in many software inventories and are rarely purchased through procurement. Endpoint protection may record the browser process but not the dozen extensions loaded inside it. Network controls see encrypted traffic to a web store, not the permissions granted within the browser.

There is a second gap. Many organisations manage the device but not the browser profile. A user signed into a personal browser account can synchronise extensions onto a managed laptop, and a user on an unmanaged device can reach the same SaaS estate with the same extensions. Conditional access can govern the user and device; it cannot inspect the toolbar.

Permission scope is the real inventory unit

A list of extension names is not an inventory. The useful record includes the publisher, the store listing, the version, the installation route, the users affected and, most importantly, the permission scope. Broad host permissions that allow reading and changing data on all sites are materially different from a narrow utility that works on one domain. Capabilities such as debugger access, native messaging, clipboard read, download management and proxy control deserve particular scrutiny.

A practical model uses three tiers. Tier one covers extensions with broad host access or sensitive capabilities; these require explicit approval, a named business owner and a review date. Tier two covers narrower tools with limited host access; these can be approved through a lighter process. Tier three covers extensions with no meaningful data access or a purely cosmetic function; these may be permitted within a defined category. The tiers should be defined by the organisation, not copied from a vendor scorecard.

Discovery across managed and unmanaged browsers

Begin with the browsers the organisation can control. Chrome and Edge expose management policies and reporting for enrolled browser profiles, while Firefox offers enterprise policy controls. Where a managed browser profile is the target state, the inventory problem becomes tractable: policy reports the extension identifiers, versions and users, and the same policy can enforce the allowlist.

Unmanaged browsers need a different approach. Endpoint detection and response tools may reveal browser extension directories, and a lightweight script can enumerate profile folders on managed Windows and macOS devices. Neither method is complete, and neither should become a covert monitoring programme. A short user survey, run alongside a clear policy statement, will often surface the tools people rely on and the shadow utilities they have adopted. The aim is a defensible picture, not a false precision.

An allowlist that survives contact with users

A default-deny model is the cleanest control and the hardest to operate. In Chrome and Edge, policy can block all extensions and then allow named identifiers; Firefox offers comparable control through its enterprise policy settings. The allowlist should include force-installed corporate tools, approved productivity extensions and a small set of role-specific utilities.

The operating model matters more than the policy syntax. Users need a route to request an extension, and that route should ask for the business purpose, the data the extension will touch, the publisher and the intended user group. A security reviewer can then assess permission scope and publisher history. Approvals should be time-bound, typically for six or twelve months, so that abandoned tools do not become permanent fixtures.

Vendor risk without a procurement marathon

Not every extension warrants a full vendor security assessment. A tab manager and an extension that reads every page in a case-management system are not equivalent. A short assessment should establish who publishes the extension, whether the publisher is identifiable and contactable, what the privacy policy says about data collection, whether the extension requests remote code or broad host permissions, and whether ownership has changed recently. Extensions are frequently sold or abandoned, and a change of publisher can alter the risk without changing the name in the toolbar.

For regulated UK organisations, the assessment should connect to existing obligations rather than create a parallel universe. UK GDPR requirements for data protection by design, ICO guidance on security and the NCSC's cyber security principles all apply to browser-level processing. Cyber Essentials provides a useful baseline for controlled changes, though it does not specifically address extensions.

Enforcement, exceptions and drift

Enforcement should be central, documented and reversible. Browser policy can block unapproved extensions, force-install approved ones and prevent users from overriding the list. When an extension is found to be risky, the response should be a policy change pushed to the fleet, followed by session revocation where credentials or tokens may have been exposed.

Exceptions are where allowlists fail in practice. A senior manager who depends on an unapproved extension will find a way around a blunt block, often by using a personal browser. The exception process should be visible, fast enough to be credible and firm about data access. A narrow approval for a named group is better than a broad approval that quietly spreads.

Drift is continuous. Extensions update, permissions change and new ones appear. A quarterly report should compare the approved list with what is actually installed, flag new broad-permission extensions and confirm that leavers no longer have profile access. The report should go to the same governance forum that oversees SaaS and endpoint risk, not to a separate shadow IT committee with no authority.

A small estate with senior ownership

The browser extension estate is small by count and large by access. It deserves an owner, a documented allowlist and a review rhythm. The work is not a one-off audit. It is a modest, repeatable control that closes a gap between identity, endpoint and software governance, and it can be run without turning productivity tools into a security incident.