Browser extensions appear small but are in practice a software supply path of their own, carrying far-reaching privileges. They are installed with a few clicks, updated automatically and possess, depending on their permissions, full read access to the user's entire web traffic. The classic attack surface thus shifts from the endpoint itself to the third party that reads along in the browser.

For Swiss organisations this is not a fringe topic in data protection terms. Where personal data is processed in an employee's browser, for example when accessing a CRM, a payroll system or an electronic patient record, every extension with a global read grant acts like an unnoticed Processor. In the absence of a processing agreement and a permissible third-country basis, a violation of Art. 9, 16 and 17 DSG is likely. This analysis sets out the permission model of Chromium-based browsers using Microsoft Edge add-ons as an example, the most common attack patterns and a workable protective approach.

Microsoft Edge has been based on Chromium since 2020 and uses the same Extension API as Google Chrome, supplemented by its own add-ons store with its own review pipeline. Extensions declare their permissions in a manifest file, and Manifest V3 was introduced with the stated aim of a reduced privilege footprint. In reality, however, many extensions still set the host_permissions value to all_urls or equivalent patterns.

This permission allows an extension to read and modify the DOM of every visited page, read cookies, set HTTP headers and inject content. Functionally it is comparable to a persistent man-in-the-middle position over all web sessions. Manifest V3 has replaced persistent background pages with service workers and introduced declarativeNetRequest, but it does not change the fundamental data access. Whoever installs a full-access extension grants an external code base read access to all online-banking, HR and business applications.

From the OWASP and red-team perspective, four attack patterns can be observed systematically. First, the direct data exfiltrator: an extension is published as a useful tool, for instance as a note-taker, translator or coupon finder, and sends browser content unencrypted or obfuscated to an external server. Second, the change of ownership: an established extension that has been benign for years is sold by the original developer team to a third party, who then pushes malicious code via auto-update. Third, the account takeover: the credentials or API tokens of the developer account are compromised and the attacker publishes a malicious update under a legitimate identity.

Fourth, the look-alike: an extension copies name, icon and description of a known tool, for example an ad blocker or password manager, and intercepts credentials. According to publicly available reports by security researchers, Microsoft removed several malicious Edge add-ons from the store during 2024, including clusters disguised as Office productivity tools or as ad blockers. Exact figures vary by source; what matters for the risk assessment is not the individual case but the structural recurrence of this pattern.

An extension that sends browser content to an external provider constitutes an independent processing activity in data protection terms. If that content includes personal data of customers, employees or patients, the organisation as Controller is required to identify a legal basis and to record the processing in the ROPA under Art. 12 DSG. Where the recipient is located outside Switzerland and the EU, for example in the United States or in Israel, a permissible cross-border disclosure under Art. 16 and 17 DSG must be secured. Without adequacy, Standard Contractual Clauses (SCCs) and a Transfer Impact Assessment, there is an inadmissible third-country transfer.

Under the GDPR, Art. 6, 28 and 44 et seq. apply analogously. In the absence of a processing agreement and appropriate safeguards, fines of up to EUR 20 million or 4 per cent of group turnover may be imposed (Art. 83 GDPR). On top of this comes the information duty towards data subjects under Art. 13 and 14 GDPR. In practice, many organisations are unaware of the data flows triggered by their extensions. An inventory is therefore the first step of any serious compliance effort. Further structural reading in the DSG/FADP guide (German-language pillar) and in the GDPR guide.

Browser extensions fit cleanly into an ISMS based on ISO/IEC 27001:2022. Several of the 93 Annex A controls are directly on point. Annex A.5.7 (threat intelligence) requires systematic monitoring of threats, including reported store removals and CVE notices on extensions. Annex A.5.19 to A.5.22 (supplier relationships) apply towards the store operator and towards extension developers, where they are commercially mandated. Annex A.5.23 covers the use of cloud services into which extensions may export data.

On the technical side, Annex A.8.7 (protection against malware), A.8.9 (configuration management, here in particular ExtensionInstallAllowlist and ExtensionInstallBlocklist), A.8.27 (secure system and application architecture) and A.8.28 (secure coding) apply for in-house or commissioned extensions. The combination of these controls delivers a complete chain of control from procurement through configuration to ongoing monitoring. Further reading in the ISO 27001 guide.

An effective protection plan combines four blocks of measures. First, the inventory: through the management APIs of Microsoft Edge and Microsoft Intune, installed extensions can be listed per device. This list is the data foundation for any risk assessment. Second, allow-listing: with the group policies ExtensionInstallAllowlist, ExtensionInstallBlocklist and ExtensionInstallForcelist, store access is restricted to vetted extensions. Microsoft offers this control both via Active Directory and via the Edge Management Service Console.

Third, hardening: enable SmartScreen, restrict synchronisation and third-party cookies, prefer Manifest V3 capable versions and route automatic updates through an approval workflow. Fourth, monitoring: telemetry and SIEM integration detect auto-updates with permission expansion. SIDD practice additionally recommends a quarterly review of all approved extensions, linked to the supplier list under Annex A.5.19. For organisations with high sensitivity, such as law firms, hospitals or pension funds, a default-deny model with a short, manually approved extension list is appropriate.

Some Swiss organisations develop their own Edge add-ons, for example to integrate an internal CRM, a single sign-on tool or a template browser. The principle of least privilege applies: host_permissions should be restricted exclusively to concrete origins, never to all_urls. Service workers should only read the data fields required for the function and must secure every transmission over HTTPS with modern TLS configuration.

Before publication, threat modelling along STRIDE, a code review focused on Content Security Policy and a penetration test against the extension's backend endpoint are recommended. ISO/IEC 27001 Annex A.8.25 (secure development lifecycle) and A.8.28 (secure coding) provide the framework. In operations, the signing keys of the developer account should be held in a hardware token or cloud HSM; a compromised key allows attackers to deliver a malicious update through the official store. For the testing phase, a targeted penetration test focused on the extension-to-backend interface is well suited.

Browser extensions are an example of shadow IT that cannot be controlled by prohibition but only through inventory, governance and monitoring. SIDD and Priverion typically accompany Swiss organisations in three phases. First, the inventory: we capture the installed extensions through endpoint management or a short technical sampling, classify them by risk and map them to the respective data flows. Second, the design: we develop an allow- and blocklist, integrate it into the existing Edge or Intune configuration, and complement internal directives and the ROPA.

Third, the assurance: a penetration test reviews in-house extensions and their backend, an ISMS to ISO/IEC 27001 provides the lasting steering framework, and ongoing advice from our Swiss data protection advisor and EU Data Protection Officer ensures legally sound handling. Leaving the browser layer ungoverned risks fines under Art. 60 DSG of up to CHF 250,000 against the responsible natural person and, under the GDPR, sanctions of up to EUR 20 million. The investment in structured extension management is regularly marginal compared with these risks.