Enterprise Browser Security: Managing Chrome Extensions and Browsing Risk at Scale

Chrome extensions operate in a privileged execution context inside the browser. An extension that requests the <all_urls> host permission in its manifest has the ability to read and modify all content on every page the user visits. This includes reading the DOM before a form is submitted, which means the extension can capture usernames and passwords as they are typed, before the browser sends them over HTTPS. It includes reading authentication cookies and tokens from web application responses, which enables session hijacking without needing the user's credentials. It includes injecting scripts that modify page content, redirect navigation, or silently submit forms on the user's behalf.

The Chrome Web Store vets extensions using automated scanning and manual review, but the review process does not prevent all malicious or compromised extensions from reaching users. Extensions that are initially benign can be updated to include malicious functionality after passing review. Extensions can be acquired by malicious actors who purchase the developer accounts that published them and push malicious updates to the existing installed base. The 2024 enforcement action that removed over 280 extensions from the Web Store demonstrated that large-scale malicious extension campaigns do reach enterprise users at scale.

Beyond extensions, the browser is the primary storage location for credentials in most enterprise environments without a centralized password manager. Chrome's built-in password manager stores credentials in the SQLite database Login Data under the user profile directory. On Windows, the database encryption key is protected by the Windows Data Protection API (DPAPI), which means any process running as the same user can decrypt it without the user's password. Malware that runs as the user context, including malicious extensions executing in the renderer process, can access browser-stored credentials. Session cookies stored in the browser's Cookies database are similarly accessible to malware with user-level access, enabling session hijacking for any authenticated web application session the user has open.

Before implementing any extension controls, you need an accurate inventory of what is currently installed. Most enterprises discover significant surprises when they run their first fleet-wide extension audit: extensions with full-page read access to all URLs installed by thousands of users, extensions that have not been updated in years and may contain known vulnerabilities, and shadow extensions installed via sideloading that bypass the Chrome Web Store entirely.

Chrome Browser Cloud Management (CBCM) is Google's free SaaS platform for managing enrolled Chrome browsers. When browsers are enrolled in CBCM, the management console provides a centralized view of all installed extensions across every enrolled device. The Extensions report shows extension name, ID, version, permissions, number of users with the extension installed, and whether the extension is force-installed, allowed, or blocked by policy. This is the fastest path to a complete extension inventory if CBCM enrollment is already deployed. CBCM enrollment requires installing the Chrome Browser enrollment token as a Windows registry value or macOS plist entry.

For environments without CBCM, endpoint detection and response (EDR) tools that collect file system and registry telemetry can enumerate installed extensions. On Windows, Chrome extensions for the system-level installation are stored under C:\\Program Files\\Google\\Chrome\\Application\\[version]\\Extensions and per-user extensions under C:\\Users\\[username]\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions. Each extension directory contains a manifest.json file. Parsing the permissions array from each manifest and filtering for entries containing <all_urls>, http://*/*, or https://*/* identifies all extensions with broad host permissions. This can be scripted and run across a fleet via your endpoint management platform.

Extension risk classification should use at least four signals: the scope of host permissions requested (all URLs vs. scoped to specific domains), the verification status of the publisher (Chrome Web Store verified badge vs. unverified), the last update date of the extension (extensions not updated in over 18 months are higher risk due to potential abandoned maintenance), and the number of active users (very low-install-count extensions have received less scrutiny and present higher risk). An extension that requests all URLs, is published by an unverified publisher, and has fewer than 1,000 installs globally warrants immediate evaluation before it remains installed on enterprise endpoints.

Chrome Enterprise policy is the mechanism for controlling browser behavior at scale. Policies can be deployed via Windows Group Policy (GPO), Active Directory, Microsoft Intune (MDM), Jamf or other macOS MDM platforms, and Chrome Browser Cloud Management. The policy names, values, and behaviors are consistent across deployment methods; only the delivery mechanism differs.

The ExtensionInstallAllowlist policy specifies extension IDs that users are permitted to install. The ExtensionInstallBlocklist policy specifies extension IDs that are blocked. Setting ExtensionInstallBlocklist to ["*"] blocks all extension installation by default, with exceptions only for extensions explicitly listed in ExtensionInstallAllowlist. This default-deny model is the most secure starting point but requires building an allowlist before enforcement. The ExtensionInstallForcelist policy specifies extensions that are automatically installed for all users covered by the policy, without user interaction. Force-installing security tools such as your EDR browser extension, SSO helper extensions, or enterprise password manager extensions ensures they are present regardless of user action.

For blocking sideloaded extensions, the ExtensionInstallSources policy specifies which URLs are permitted to serve extensions for installation. Setting this to an empty list or removing it entirely, combined with the DeveloperToolsAvailability policy set to 2 (disallow developer tools for users covered by policy), prevents loading unpacked extensions from local directories. The ExtensionSettings policy provides a more granular extension management model that combines allowlist, blocklist, force-install, and per-extension configuration in a single JSON policy object, and is the recommended approach for complex extension management requirements.

Before moving from audit to enforcement, the operational risk of breaking productivity tools that teams rely on must be managed. The recommended sequence is: deploy Chrome Browser Cloud Management enrollment first, run the Extensions report for two to four weeks to build an accurate inventory, classify extensions into approved (force-install or allow), under review (temporarily allowed pending evaluation), and blocked (immediate blocklist addition) categories, then deploy the allowlist policy in a pilot group before broad rollout. The most disruptive scenario in an allowlist rollout is a business-critical SaaS application that requires a specific extension for functionality; identifying these before enforcement through the inventory phase prevents rollout failures.

Browser-native password storage represents a significant risk in enterprise environments where endpoints are shared, unmanaged, or accessible to malware. Chrome's Login Data file stores credentials encrypted with a key derived from the Windows DPAPI or macOS Keychain. DPAPI encryption is user-context-bound, meaning any process that runs as the logged-in user can request decryption without any additional authentication. Infostealers such as Redline, Raccoon, and Vidar routinely target this file because it provides complete credential access without requiring privilege escalation.

The enterprise password manager model provides substantially better security. Products like 1Password, Bitwarden, Dashlane Business, and CyberArk Workforce Password Management store credentials in an encrypted vault protected by a master password or hardware key that is separate from the operating system user session. The vault is not decryptable by malware running as the user without the master password or hardware authenticator. Browser extensions for enterprise password managers use strict host-permission scoping and are deployed via force-install policy to ensure consistent coverage.

The Chrome policy to consider in this context is PasswordManagerEnabled. Setting it to false disables the built-in Chrome password manager and prevents Chrome from offering to save new credentials. This policy does not delete existing saved passwords but stops new ones from being added. Combined with a force-installed enterprise password manager extension, this enforces that all new credentials are stored in the managed vault rather than the local browser database. This transition requires user communication because it removes a familiar workflow; phasing it in alongside the password manager rollout reduces friction.

For session cookie protection, Chrome's App-Bound Encryption (introduced in Chrome 127) encrypts cookies with a key tied to the application identity, preventing other processes running as the user from decrypting them without bypassing Chrome's helper service. This feature is currently limited to Windows and is an improvement over the previous DPAPI-only model, but it does not prevent malicious extensions from accessing cookies within the browser context. Extension-based session theft remains possible regardless of App-Bound Encryption because extensions execute inside Chrome's renderer process, not as external processes.

Browser isolation is a technology that runs the browser rendering engine in a remote environment, transmitting only a visual stream of pixels to the user's endpoint rather than executing web content locally. If the user visits a page containing a drive-by exploit, the exploit executes in the isolated cloud or virtual machine environment, not on the endpoint. The endpoint receives only a video stream of the rendered page. Menlo Security, Zscaler Browser Isolation, and Ericom Shield are the primary enterprise browser isolation products. Native browser isolation from Google (Chrome OS Flex with remote desktop) and Microsoft (Microsoft Defender Application Guard) provide isolation for specific use cases without a third-party product.

Browser isolation is not a universal deployment; the latency and UX degradation for interactive web applications make it impractical as a full-fleet default. The appropriate use cases are: contractor and third-party vendor access to internal web applications (where you want to prevent data download and restrict copy-paste), access to external URLs from high-risk user populations (finance team clicking on vendor links, executives with high phishing targeting), and browsing to uncategorized or newly registered domains that DNS filtering does not outright block. For these specific populations and use cases, isolation adds substantial protection against web-delivered exploits and phishing credential capture.

The managed browser profile model is the baseline for enterprise browser security even without isolation. A managed browser profile is one enrolled in Chrome Browser Cloud Management or pushed policies via GPO/MDM. Enforcing that work SaaS applications are only accessed from the managed profile requires combining two controls: BrowserSignin policy set to 2 (force sign in to managed account) and an IdP-level device compliance check that only allows authentication from enrolled, managed browsers. For Google Workspace environments, Context-Aware Access can enforce that Google services are only accessible from managed Chrome browsers with compliant policies applied. For other SaaS applications using SAML or OIDC, this requires a Secure Web Gateway or CASB that inspects the browser identity before forwarding the authentication.

The separation between personal and work browsing is relevant for BYOD environments. Chrome profiles provide some separation: cookies, passwords, and extensions are stored per-profile and do not cross-contaminate between profiles. A malicious extension installed in one profile cannot access data from another profile. In BYOD environments, enforcing that work-related browsing occurs exclusively in a managed Chrome profile (enrolled and policy-controlled) while personal browsing happens in a separate unmanaged profile provides workable separation without requiring device management enrollment.

Chrome Browser Cloud Management provides an Audit Log in the Admin Console that captures browser-related security events. Events include: extension install and removal, extension blocklist violations (a user attempted to install a blocked extension), browser enrollment and unenrollment, policy configuration changes, and unsafe site visit attempts. The Audit Log is accessible in the CBCM console under Reports > Audit Log and can be exported via the Reports API for integration with a SIEM or security data lake.

The extension install event is particularly valuable for detecting shadow IT tool adoption and potential malicious extension installation. Each event includes the extension ID, name, version, and the user who installed it. A detection rule that alerts on extension installations of extensions that are not in the approved allowlist surfaces unapproved extensions in near real-time. If the default-deny allowlist policy is enforced, these events represent policy violations and warrant investigation into why the user was able to install a non-allowlisted extension, which could indicate a policy deployment gap on specific devices.

For environments without CBCM, Windows Event Log and MDM report data can surface extension changes. On Windows, Chrome writes extension install and removal events to the Windows Application Event Log when certain policy conditions are met. EDR tools that monitor file system changes under the Chrome Extensions directory can surface new extension directories being created, which corresponds to a new extension installation. Correlating extension install events against a known-good allowlist using EDR telemetry provides similar coverage to CBCM without requiring browser enrollment.

Beyond extension monitoring, Chrome Safe Browsing Enhanced Protection (configurable via the SafeBrowsingProtectionLevel policy set to 2) provides real-time URL checks against Google's phishing and malware database, including predictive phishing protection that evaluates page content characteristics in addition to URL reputation. Enhanced Protection sends URL data to Google for real-time analysis, which has privacy implications worth considering, but it detects new phishing pages significantly faster than Standard Protection, which uses a locally cached list updated every 30 minutes.