Les extensions de navigateur semblent petites, mais constituent dans la pratique un vecteur de livraison logicielle propre aux pouvoirs étendus. Elles s'installent en quelques clics, se mettent à jour automatiquement et, selon les permissions accordées, disposent d'un accès complet en lecture à l'intégralité du trafic web des utilisateurs. La surface d'attaque classique se déplace ainsi de l'appareil terminal lui-même vers le tiers qui lit dans le navigateur.

Pour les entreprises suisses, ce n'est pas un sujet marginal en droit de la protection des données. Lorsque des données personnelles sont traitées dans le navigateur d'un collaborateur, par exemple lors de l'accès à un CRM, un système de paie ou un dossier électronique du patient, toute extension disposant d'une autorisation de lecture globale agit comme un sous-traitant non remarqué. En l'absence d'un contrat de sous-traitance et d'une base valide de transfert vers des pays tiers, une violation des art. 9, 16 et 17 LPD est probable. Cette analyse présente le modèle de permissions des navigateurs basés sur Chromium à l'exemple des modules complémentaires Microsoft Edge, les schémas d'attaque les plus fréquents et une approche de protection praticable.

Microsoft Edge est basé sur Chromium depuis 2020 et utilise la même API d'extension que Google Chrome, complétée par un store de modules complémentaires propre avec son propre pipeline de vérification. Les extensions déclarent leurs permissions dans un fichier manifest, depuis Manifest V3 avec la promesse d'un périmètre de privilèges réduit. Dans la réalité, cependant, de nombreuses extensions continuent à définir la permission host_permissions avec la valeur all_urls ou des patterns équivalents.

Cette permission permet à l'extension de lire et de modifier le DOM de chaque page visitée, de lire les cookies, de définir des en-têtes HTTP et d'injecter du contenu. Fonctionnellement, elle est comparable à un accès Man-in-the-Middle persistant sur toutes les sessions web. Manifest V3 a bien remplacé les pages d'arrière-plan persistantes par des Service Workers et introduit declarativeNetRequest, mais ne change rien à l'accès fondamental aux données. Quiconque installe une extension avec accès total accorde à un codebase externe une autorisation de lecture sur toutes les applications bancaires en ligne, RH et métier.

Du point de vue OWASP et Red Team, quatre schémas d'attaque peuvent être systématiquement observés. Premièrement, l'exfiltrateur de données direct : une extension est publiée comme outil utile, par exemple un bloc-notes, un traducteur ou un chercheur de coupons, et envoie le contenu du navigateur de manière non chiffrée ou masquée à un serveur externe. Deuxièmement, le changement de propriété : une extension établie, restée inoffensive pendant des années, est vendue par l'équipe de développeurs originale à un tiers qui envoie ensuite du code malveillant via une mise à jour automatique. Troisièmement, la prise de contrôle de compte : les identifiants ou jetons API du compte développeur sont compromis et l'attaquant publie une mise à jour malveillante sous une identité légitime.

Quatrièmement, le look-alike : une extension copie le nom, l'icône et la description d'un outil connu, par exemple un bloqueur de publicités ou un gestionnaire de mots de passe, et intercepte les identifiants de connexion. Selon des rapports de chercheurs en sécurité accessibles au public, Microsoft a supprimé en 2024 plusieurs modules complémentaires Edge malveillants du store, dont des clusters déguisés en outils de productivité Office ou en bloqueurs de publicités. Les chiffres exacts varient selon les sources ; pour l'évaluation des risques, c'est non pas le cas isolé, mais la récurrence structurelle de ce schéma qui est déterminante.

Une extension qui envoie le contenu du navigateur à un fournisseur externe constitue un traitement autonome en droit de la protection des données. Si des données personnelles de clients, collaborateurs ou patients en font partie, l'entreprise en tant que responsable du traitement est tenue d'identifier une base juridique et de documenter le traitement dans le registre selon l'art. 12 LPD. Si le destinataire se trouve hors de Suisse et de l'UE, par exemple aux États-Unis ou en Israël, une communication à l'étranger admissible selon les art. 16 et 17 LPD doit être assurée. Sans adéquation, clauses contractuelles types et analyse de l'impact des transferts, il s'agit d'un transfert vers un pays tiers non admissible.

Sous le RGPD, les art. 6, 28 et 44 ss s'appliquent de manière analogue. Sans contrat de sous-traitance et sans garanties appropriées, des amendes allant jusqu'à EUR 20 millions ou 4 % du chiffre d'affaires du groupe s'appliquent (art. 83 RGPD). S'y ajoute l'obligation d'information envers les personnes concernées selon les art. 13 et 14 RGPD. Dans la pratique, de nombreuses entreprises ne connaissent pas leurs flux de données déclenchés par les extensions. Un inventaire est donc la première étape de tout effort de conformité sérieux. Des structures complémentaires se trouvent dans le guide LPD et dans le guide RGPD.

Les extensions de navigateur peuvent être clairement intégrées dans un SMSI selon ISO/IEC 27001:2022. Plusieurs des 93 contrôles Annexe A sont directement applicables. L'Annexe A.5.7 (Renseignements sur les menaces) oblige à surveiller systématiquement les menaces, y compris les suppressions du store signalées et les avis CVE relatifs aux extensions. Les Annexes A.5.19 à A.5.22 (relations fournisseurs) s'appliquent vis-à-vis de l'exploitant du store et des développeurs d'extensions, dans la mesure où ils sont mandatés commercialement. L'Annexe A.5.23 couvre l'utilisation de services cloud vers lesquels des extensions peuvent exporter des données.

Dans le domaine technique, l'Annexe A.8.7 (protection contre les logiciels malveillants), A.8.9 (gestion de la configuration, notamment ExtensionInstallAllowlist et ExtensionInstallBlocklist), A.8.27 (architecture système et applicative sécurisée) et A.8.28 (codage sécurisé) pour les extensions propres ou mandatées sont applicables. La combinaison de ces contrôles fournit une chaîne de contrôle complète depuis la procurement jusqu'au monitoring continu, en passant par la configuration. Approfondissement dans le guide ISO 27001.

Un plan de protection efficace combine quatre blocs de mesures. Premièrement, l'inventaire : via les API d'administration de Microsoft Edge et Microsoft Intune, les extensions installées par appareil peuvent être listées. Cette liste est la base de données pour toute évaluation des risques. Deuxièmement, l'allowlisting : avec les stratégies de groupe ExtensionInstallAllowlist, ExtensionInstallBlocklist et ExtensionInstallForcelist, l'accès au store est limité aux extensions vérifiées. Microsoft propose ce pilotage aussi bien via Active Directory que via la console Edge Management Service.

Troisièmement, le durcissement : activer SmartScreen, restreindre la synchronisation et les cookies tiers, préférer les versions compatibles Manifest V3 et convertir les mises à jour automatiques en flux de travail d'approbation. Quatrièmement, le monitoring : la télémétrie et la connexion SIEM détectent les mises à jour automatiques avec élévation de permissions. La pratique SIDD recommande en outre une révision trimestrielle de toutes les extensions autorisées, couplée à la liste de fournisseurs selon l'Annexe A.5.19. Pour les entreprises à haute sensibilité, par exemple les cabinets d'avocats, les hôpitaux ou les caisses de pension, un modèle de refus par défaut avec une liste d'extensions courte approuvée manuellement est indiqué.

Certaines entreprises suisses développent leurs propres modules complémentaires Edge, par exemple pour l'intégration d'un CRM interne, d'un outil d'authentification unique ou d'un navigateur de modèles. Le principe des permissions minimales s'applique ici : host_permissions doit être strictement limité à des origins concrets, jamais à all_urls. Les Service Workers ne peuvent lire que les champs de données nécessaires à la fonction et doivent sécuriser toute transmission via HTTPS avec une configuration TLS moderne.

Avant la publication, un Threat Modeling selon STRIDE, une révision du code axée sur la Content Security Policy et un test de pénétration contre l'endpoint backend de l'extension sont recommandés. L'ISO/IEC 27001 Annexe A.8.25 (cycle de développement sécurisé) et A.8.28 (codage sécurisé) constituent le cadre. En exploitation, les clés de signature du compte développeur doivent être conservées dans un token matériel ou un Cloud-HSM ; une clé compromise permet aux attaquants de livrer une mise à jour malveillante via le store officiel. Pour la phase de test, un test de pénétration ciblé avec accent sur l'interface extension-backend est approprié.

Les extensions de navigateur sont un exemple d'informatique fantôme qui ne peut être maîtrisée non par des interdictions, mais uniquement par l'inventaire, le pilotage et le monitoring. SIDD et Priverion accompagnent les entreprises suisses typiquement en trois phases. Premièrement, l'état des lieux : nous recensons les extensions installées via la gestion des endpoints ou via un échantillon technique court, les classifions par risque et les associons aux flux de données respectifs. Deuxièmement, la conception : nous élaborons une liste blanche et une liste noire, les intégrons dans la configuration Edge ou Intune existante et complétons les directives internes ainsi que le registre des activités de traitement.

Troisièmement, la sécurisation : un test de pénétration vérifie les extensions propres et leur backend, un SMSI selon ISO/IEC 27001 fournit le cadre de pilotage pérenne, et le conseil continu de notre conseiller à la protection des données Suisse ainsi que du DPO UE garantit un traitement juridiquement sûr. Quiconque laisse la couche navigateur sans pilotage risque selon l'art. 60 LPD des amendes allant jusqu'à CHF 250 000 à l'encontre de la personne physique responsable ainsi que des sanctions allant jusqu'à EUR 20 millions sous le RGPD. L'investissement dans une gestion structurée des extensions est marginal par rapport à ces risques.