Browser Extension Security Guide: Permissions and Malicious Extensions

Browser extensions run inside the pages where users sign in, read email and handle customer data, yet most organisations cannot say which extensions are installed, what they can read or who publishes them. One extension with access to all sites can read page content, capture form input and reach session cookies, and it updates itself silently from a store the organisation does not control. This guide goes deeper than general browser hardening: it covers the extension permission model, how malicious, hijacked and AI extensions get in, inventory and risk scoring, allowlisting with Chrome, Edge and Firefox policy, and response when an approved extension turns bad. It is written for endpoint, identity and security operations teams. For the wider picture, including enterprise browsers and browser DLP, see the Enterprise Browser and Browser Security Guide.

Key takeaways

• Permissions are the risk, not the name. Host access to all sites, or APIs such as debugger, proxy, nativeMessaging and cookies, decides what an extension can steal. Score on capability first, publisher second.
• Default deny, allow by ID. The ExtensionSettings policy in Chrome, Edge and Firefox blocks everything, allows approved IDs, blocks sensitive permissions and keeps extensions off named sites. It overrides the older allowlist, blocklist and force-install policies.
• An allowlist does not stop a hijacked update. The Cyberhaven compromise pushed a malicious version of an approved extension through normal auto-update. Keep every extension away from identity, admin and finance sites, and watch for version and permission changes.
• Close the side doors. Developer mode, unpacked and command-line loading, external installs, second browsers and personal profiles all bypass a store allowlist.
• Plan the removal before you need it. Know how to remove an extension fleet-wide in minutes and which sessions to revoke afterwards.

What an extension can actually do

An extension is a package of JavaScript and a manifest declaring the permissions it wants. Chromium browsers (Chrome, Edge and others) share one extension platform; Firefox add-ons use the largely compatible WebExtensions API. Once installed, an extension acts within the user's signed-in sessions: it does not need the password if it can read the page or the cookie.

Host permissions decide which sites an extension can read and change, from one domain to every site through <all_urls>. API permissions grant browser capabilities. Users see a warning at install, but Chrome's permissions reference lists no warning of their own for cookies, webRequest, scripting or the base identity permission; their reach comes from the host permissions paired with them.

The tiers are a starting point. Microsoft's browser extension assessment puts it plainly: "Risk is subjective. Each organization should determine the types of risk they're willing to take on."

How malicious and hijacked extensions get in

MITRE ATT&CK tracks this as T1176.001 Browser Extensions, under Persistence. It covers installs from a local file, a custom URL or a store, malicious extensions disguised as legitimate ones, attackers changing an extension's update URL, and edits to Chromium's Preferences or Secure Preferences files while the browser is closed so an extension loads silently. Its procedure examples include infostealer families and state-linked espionage groups. The entry routes:

• Rogue extension from the store: a useful-looking tool (PDF converter, VPN, AI assistant, coupon finder) that harvests data from day one, or after a clean first release builds trust.
• Extension hijacking: the publisher's developer account is phished or the extension is sold, and a malicious update reaches every user through auto-update. This is the browser extension supply chain risk: store and allowlist both see a trusted ID.
• Sideloaded extension: loaded unpacked through developer mode, from the command line, or planted by malware already on the device.
• Policy abuse: an attacker with admin rights adds an ID to ExtensionInstallForcelist or ExtensionSettings, so the browser installs it and stops the user removing it.

The Cyberhaven Chrome extension breach is the reference case for extension hijacking. According to TechTarget, an employee was phished around 24 December 2024 by an email posing as a Google warning about Chrome Web Store removal, leading to a malicious OAuth application called "Privacy Policy Extension". The attacker gained publishing access and uploaded malicious version 24.10.4, which Cyberhaven detected at 11:54 PM UTC on 25 December and removed within 60 minutes. Researchers quoted in the report found 36 malicious extensions in the wider campaign. For customers, the extension was legitimate and allowlisted; the bad code came through the normal update channel.

AI and GenAI browser extensions

AI browser extensions (sidebars, writing assistants, note takers, "chat with this page" tools) are among the riskiest categories because their purpose requires reading the page. Most request access to all sites and send content to a model provider that has never been through procurement or a data protection review.

• Leakage by design: an assistant that summarises the open tab sends whatever is on screen, including CRM records, source code and HR cases, to an external service. Treat it as a data processor.
• Fake and returning AI extensions: according to SecurityWeek (11 August 2026), "AI Sidebar with DeepSeek, ChatGPT, Claude and more" was flagged in December 2025 for scraping ChatGPT and DeepSeek conversations, removed from the Chrome Web Store in January 2026, and was back by August 2026, having had more than 300,000 installs. A clean version was followed two weeks later by one adding code that fired on update. Store presence is not vetting.
• Agentic extensions: tools that click, fill and submit carry the user's authority on every site in scope. See the Browser and Computer-Use Agent Guide.

Approve one or two AI extensions that match your sanctioned AI services, block the rest, and keep even the approved one off your identity provider and regulated applications with host restrictions. For paste and upload controls see the Generative AI Data Loss Prevention Guide.

Inventory and risk scoring

Extension sprawl builds quietly: several extensions per user, many installed years ago, some no longer in any store. An unmanaged browser extension on a personal profile is invisible to most tooling.

• Browser management reporting: Chrome Enterprise Core includes extension reporting; manage Edge through Intune, Group Policy or the Edge management service.
• Endpoint inventory: Microsoft Defender Vulnerability Management lists Edge, Chrome and Firefox extensions on Windows devices with Requested permissions and Permissions risk columns, plus the DeviceTvmBrowserExtensions and DeviceTvmBrowserExtensionsKB advanced hunting tables (standalone licence or add-on required).
• Key on ID, not name: Chrome and Edge IDs are 32-character strings at the end of the store URL and stable across versions; Firefox IDs appear under "Copy add-on ID" on addons.mozilla.org or in about:support. Collect every profile, not just Default.

Re-score whenever version, permissions or publisher change. Chrome disables an extension until the user accepts a newly added warning-triggering permission, but that is a user decision, not a review, and a malicious update that adds no permission triggers nothing.

Allowlist, blocklist or permission policy

Small organisations: block the critical permissions plus a short blocklist, then move to an allowlist of 10 to 30 extensions within a quarter. Large organisations: default-deny with an owner per extension, a request workflow (Chrome supports user extension requests natively), separate tiers for developers and privileged administrators, and host restrictions on identity and admin sites for everyone.

Browser extension management by policy

Google states that ExtensionSettings "overrides those policies if they're also set"; Microsoft lists ExtensionInstallAllowlist, ExtensionInstallBlocklist, ExtensionInstallForcelist, ExtensionAllowedTypes and ExtensionInstallSources as policies it can overwrite in Edge. Pick one model rather than mixing them.

• Per-ID scopes do not inherit: an extension with its own entry uses only that entry, so repeat blocked_permissions and host restrictions on each approved ID.
• Where it lives: Edge Group Policy Microsoft Edge > Extensions > Configure extension management setting, stored under HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings; Chrome under HKLM\SOFTWARE\Policies\Google\Chrome or the Google Admin console. Validate the JSON before deployment, as Microsoft recommends.
• ExtensionInstallForcelist: still used to push security extensions (ID plus update URL), and a persistence target, so monitor who writes it.
• Close sideloading: set Edge ExtensionDeveloperModeSettings to 1 (Disallow, Edge 128 and later); in Chrome block external extensions (any not installed from the Chrome Web Store), block command-line loading through the install type settings, and disable unpublished extensions. Force-installed extensions are exempt from the unpublished setting.
• Every browser and profile: apply the same policy to each permitted browser, remove the rest, force corporate sign-in, and on managed Macs use the Apple Extensions payload, which can block extension point types such as Safari.

Manifest V3 and the Chrome Web Store

Manifest V3 "removes the ability for an extension to use remotely hosted code", replaces background pages with service workers and deprecates blocking webRequest in favour of declarativeNetRequest. No remote code means reviewers and your own scoring see the logic that will run. Chrome disabled Manifest V2 extensions for all users from 24 July 2025; Chrome 138 was the final version supporting them even with the ExtensionManifestV2Availability policy, and remaining Manifest V2 items were removed from the store on 31 August 2026. Any Manifest V2 extension still in your inventory is unmaintained and a finding.

Manifest V3 does not stop a malicious update, limit all-sites host access or stop an extension sending data it may read. Store policy demands a single purpose, "the narrowest permissions necessary", limited use of user data and no obfuscation, but both incidents above passed through the store. Your approval decides what runs.

Where identity fits

Extensions sit on top of identity: they can read session cookies and bearer tokens in pages, observe single sign-on flows, and some hold their own OAuth tokens to a vendor back end. Treat each approved extension as a non-human integration with an owner, purpose and data scope. Put the IdP and privileged consoles in runtime_blocked_hosts for all extensions, and limit what a stolen cookie is worth with short sessions and re-authentication; see the Token and Session Security Guide. If you publish extensions, the store developer account is a publisher identity: protect it with phishing-resistant MFA and review OAuth consents, the route used against Cyberhaven.

How to implement

1. Inventory in report-only mode (weeks 1 to 3): bring every managed browser under central management and collect extensions, versions, permissions and store status. Change nothing yet.
2. Score and decide: apply the risk model, assign owners, draft the allowlist, and remove anything known malicious, unpublished or Manifest V2 straight away.
3. Baseline for everyone: deploy blocked_permissions for critical APIs, runtime_blocked_hosts for identity and admin sites, and block developer mode and external installs. These rarely break workflows.
4. Pilot default deny: set * to blocked (not removed) for IT and security, then one or two business units with the request workflow live. Measure blocked attempts and requests for two to four weeks.
5. Roll out by ring, then switch to removed once the allowlist is stable, so unapproved extensions are uninstalled.
6. Rollback: keep policy JSON in version control. Reverting * to allowed restores user installs at the next policy refresh; removed extensions must be reinstalled.

Detection, response and measurement

• Policy tampering: registry writes to ExtensionInstallForcelist or ExtensionSettings by anything other than the management agent (Sysmon Event ID 13, registry value set), and changes to managed policy files on macOS and Linux.
• Profile edits: writes to Preferences or Secure Preferences while the browser is not running.
• Install then beacon: ATT&CK detection strategy DET0044 looks for a new extension followed by unusual file writes or outbound connections from the browser process to untrusted domains.
• Version drift: a new version of an allowlisted extension, especially after dormancy or with new permissions, triggers re-review.
• Session reuse: sign-ins reusing a session from a new location shortly after an extension change may indicate cookie theft (T1539) or browser session hijacking (T1185).

Response to a malicious extension: find every device, profile and version installed during the exposure window; set the ID to removed (Firefox: blocked) and confirm refresh; revoke sessions and tokens for affected users on every site in the extension's host scope and reset credentials typed there; hunt for its network indicators in proxy and DNS logs. See the Infostealer Threat Guide for cookie theft follow-up.

Metrics:

• Percentage of managed browsers and profiles reporting the default-deny policy (target 100%).
• Distinct extension IDs in use outside the allowlist (target zero after rollout).
• High-risk installs without host restrictions on identity sites.
• Hours from a malicious extension report to removal on all devices.
• Median days to decide an extension request (long queues push users to unmanaged browsers).

Common failure patterns

• Trusting the ID forever: approving once and never re-reviewing. Cyberhaven showed an approved ID can ship malicious code overnight.
• Locking down one browser: enforcing policy in Chrome while Edge, Firefox or a portable browser runs unmanaged.
• Leaving developer mode open: blocking store installs but allowing unpacked loading.
• Mixing policies: setting ExtensionInstallBlocklist alongside ExtensionSettings and assuming both apply.
• Treating a store listing as vetting: an extension removed for stealing AI chats returned to the store months later.
• Forgetting developer tools: IDE extensions carry the same supply chain risk with more access to secrets, as the GlassWorm campaign showed.

Framework mapping

Practitioner checklist

• Inventory extensions on every managed browser and profile by ID, with permissions and store status.
• Score each on host scope, permissions, source, data flow, publisher and change history, and assign an owner.
• Deploy ExtensionSettings with a default-deny * scope and approved IDs only; retire the older allowlist and blocklist policies.
• Block debugger, proxy and nativeMessaging, and put identity, admin and finance sites in runtime_blocked_hosts for every extension.
• Disable developer mode, external and command-line installs and unpublished extensions in every permitted browser.
• Approve a small set of AI extensions tied to sanctioned AI services and block the rest.
• Alert on extension policy writes, Preferences edits and new versions of allowlisted extensions.
• Keep a tested runbook to remove an extension fleet-wide and revoke affected sessions within hours.

Standards and references

• Google Chrome Enterprise Help: Configure ExtensionSettings policy
• Microsoft Learn: Detailed guide to the ExtensionSettings policy (Microsoft Edge)
• Mozilla: Firefox Enterprise Policy Reference, ExtensionSettings
• MITRE ATT&CK: T1176.001 Software Extensions: Browser Extensions
• Chrome for Developers: Permissions reference
• Chrome for Developers: Manifest V2 support timeline
• Chrome for Developers: Chrome Web Store Program Policies
• Microsoft Learn: Browser extensions assessment in Microsoft Defender Vulnerability Management

Related NHI Mgmt Group resources: Enterprise Browser and Browser Security Guide · Application Allowlisting Guide · Software Supply Chain Security Guide · Shadow AI Discovery Guide · Cyberhaven Chrome Extension Breach