Politique de sécurité des extensions navigateur en entreprise

Politique de sécurité des extensions navigateur en entreprise

Une extension de navigateur n’est pas un petit confort d’interface : c’est du code tiers exécuté au plus près des applications métier, des cookies de session et des contenus affichés. Une politique d’autorisation doit donc traiter chaque extension comme un fournisseur logiciel ayant potentiellement accès aux identités, pas comme un bouton de barre d’outils un peu décoratif.

Explication de la marmotte

Une extension ressemble à un employé extérieur qui reçoit un badge pour circuler dans des bureaux et lire certains dossiers. Le badge peut être donné à une personne sérieuse, puis finir dans les mains d’un repreneur beaucoup moins regardant. Le problème n’est pas le badge initial, mais ce qu’il permet encore plus tard.

→ Lire l’explication complète de la marmotte

Extension navigateur : une dépendance logicielle à privilèges

Une extension est distribuée par un magasin d’extensions, signée par son éditeur et installée dans un navigateur. Cette chaîne protège principalement contre l’installation arbitraire d’un paquet modifié localement. Elle ne garantit ni la continuité de l’éditeur, ni la stabilité fonctionnelle du code, ni l’absence d’abus des permissions accordées.

Les navigateurs modernes isolent une extension dans un contexte distinct de la page. Cette isolation limite certaines attaques entre scripts, mais elle ne transforme pas l’extension en tiers inoffensif. Une extension munie de la permission host_permissions sur https://*/* peut lire ou modifier le contenu des pages couvertes. Avec les permissions cookies, webRequest, declarativeNetRequest ou une interface de débogage autorisée, elle peut influencer les requêtes, observer des identifiants de session ou détourner les flux affichés.

Le compromis central est brutal : autoriser des extensions améliore la productivité locale, mais introduit du code évolutif dans le périmètre de confiance des applications consultées. La recommandation est donc de bloquer toute installation par défaut et d’autoriser explicitement une liste courte d’extensions justifiées, réévaluées et techniquement inspectables. L’exception ne doit pas être l’extension bloquée. L’exception est l’extension autorisée.

Une extension de gestionnaire de mots de passe, de sécurité web ou de filtrage peut nécessiter un accès étendu. C’est acceptable si son éditeur, son cycle de mise à jour, ses permissions et son modèle de données ont été évalués. Une extension de conversion de fichiers qui réclame l’accès à toutes les pages mérite en revanche le même accueil qu’un script reçu par courriel : pas de panique, mais pas d’exécution non plus.

Le magasin d’extensions est un canal de distribution, pas une autorité de sécurité métier. Le badge de validation d’une boutique prouve surtout qu’un paquet a passé les contrôles de la boutique à un instant donné. Vingt ans de logiciels distribués apprennent que « validé dans le store » et « acceptable dans un poste administré » vivent dans des univers qui se croisent rarement.

Rachat, mise à jour silencieuse et détournement des sessions

Le risque le plus sous-estimé est la dérive après installation. L’identifiant d’une extension reste généralement stable lors d’une mise à jour. Le navigateur vérifie alors la signature et télécharge une nouvelle version depuis le canal officiel. Si l’éditeur est racheté, si son compte de publication est compromis ou si son dépôt de construction est empoisonné, une version ultérieure peut changer de comportement sans action visible de l’utilisateur.

Une mise à jour qui ajoute une permission sensible doit normalement déclencher une demande d’acceptation. Ce garde-fou est insuffisant en entreprise pour trois raisons. D’abord, une permission large accordée dès l’installation laisse beaucoup de marge aux versions suivantes. Ensuite, les modèles de permissions diffèrent entre Chrome, Microsoft Edge et Firefox. Enfin, une extension peut déjà disposer d’un accès aux contenus de page sans devoir ajouter de nouvelle permission spectaculaire. Le prédateur n’a pas toujours besoin d’une nouvelle clé si la porte est déjà ouverte.

Le scénario d’attaque le plus rentable vise les sessions authentifiées. Un script injecté dans une page peut lire les champs saisis, modifier un virement avant validation, extraire des données affichées ou intercepter un jeton porté par le contenu de la page. Un cookie marqué HttpOnly n’est pas lisible par le script de page, mais cela ne protège pas les données que l’application affiche après authentification. Confondre confidentialité du cookie et confidentialité de la session applicative est une erreur classique, avec un joli potentiel de réunion de crise.

Une extension ne contourne pas systématiquement les protections du navigateur. La politique de sécurité de contenu, ou Content Security Policy, limite certaines sources de scripts pour un site. Le cloisonnement entre origines limite l’accès direct à d’autres domaines. Ces mécanismes restent nécessaires, mais une extension disposant des permissions adéquates opère souvent hors du modèle de menace prévu pour un script de site ordinaire.

La protection doit donc venir aussi de l’identité et de l’application :

• imposer une authentification multifacteur résistante au hameçonnage pour les accès à privilèges ;
• limiter la durée de vie des sessions et exiger une réauthentification pour les opérations sensibles ;
• séparer les profils ou navigateurs dédiés aux consoles d’administration, aux outils financiers et à la navigation générale ;
• appliquer le moindre privilège aux comptes, car une session compromise ne doit pas donner accès à tout le royaume ;
• revoir les protections de session avec les principes décrits dans la section Identités et les contrôles réseau de l’architecture réseau.

Aucune politique d’extensions ne protège contre une application qui autorise une modification de coordonnées bancaires avec une session vieille de huit heures et sans confirmation forte. Le navigateur n’est pas un exorciste.

Politique d’autorisation et inventaire des permissions

La politique doit être appliquée par les mécanismes de gestion centralisée du navigateur, pas par une charte demandant de « faire attention ». Chrome et Edge exposent des stratégies d’entreprise, Firefox expose des politiques administrées. Le navigateur doit être enrôlé dans la gestion de terminaux, ou Endpoint Management, et les politiques doivent être vérifiables localement.

La base de la politique tient en quatre règles :

1. bloquer l’installation de toute extension non explicitement autorisée ;
2. autoriser par identifiant d’extension, navigateur par navigateur ;
3. réserver l’installation forcée aux extensions indispensables à la sécurité ou à l’exploitation ;
4. interdire le mode développeur et le chargement d’extensions non empaquetées sur les postes standards.

L’identifiant seul ne suffit pas à l’évaluation. Le dossier d’autorisation doit contenir l’éditeur, le nom du paquet, les navigateurs concernés, les permissions demandées, les domaines accessibles, la finalité métier, le propriétaire interne, la date de revue et le mécanisme de retrait. Une extension dont le propriétaire interne est « équipe informatique » n’a pas de propriétaire. C’est un brouillard administratif avec un logo.

Les permissions doivent être lues comme des capacités, non comme une prose marketing. activeTab donne un accès temporaire à l’onglet déclenché par l’utilisateur et reste préférable à un accès permanent à toutes les pages. storage permet de stocker des données locales mais ne dit rien, à lui seul, sur leur chiffrement. nativeMessaging ouvre un canal vers un programme local déclaré : cette permission relie le navigateur au poste et mérite une revue séparée. Une extension qui charge du code distant est particulièrement dangereuse, car le paquet signé devient alors un lanceur de code dont le contenu peut varier côté serveur.

La révision doit être déclenchée par événement, pas seulement par calendrier : changement de propriétaire légal, incident public, ajout de permission, modification du domaine de mise à jour, abandon du projet ou changement de modèle économique. Une extension gratuite devenue outil de collecte publicitaire ne publie pas forcément un communiqué de presse en majuscules.

Exemple de stratégie Chrome et Edge gérée

Sur Linux, Google Chrome lit les politiques gérées sous /etc/opt/chrome/policies/managed/. Chromium et Microsoft Edge utilisent des emplacements voisins selon la distribution. Le principe reste identique : bloquer globalement, puis autoriser les identifiants approuvés.

/etc/opt/chrome/policies/managed/extensions.json

{
  "ExtensionSettings": {
    "*": {
      "installation_mode": "blocked"
    },
    "cjpalhdlnbpafiamejdnhcphjbkeiagm": {
      "installation_mode": "allowed"
    }
  }
}

Cette configuration bloque les installations non listées et autorise uBlock Origin par son identifiant Chrome. Elle ne force pas l’installation. Pour une extension requise, remplacer allowed par force_installed et ajouter update_url uniquement lorsque la source de mise à jour est celle attendue par l’éditeur ou le magasin officiel.

Après application, contrôler la politique dans chrome://policy et vérifier l’extension dans chrome://extensions. Un fichier JSON présent mais ignoré par le navigateur ne protège rien. C’est une décoration de système de fichiers, activité historiquement très appréciée des audits pressés.

Tester la politique sur un poste pilote avec un compte non administrateur. Vérifier trois cas : installation d’une extension inconnue refusée, installation d’une extension autorisée acceptée, chargement d’une extension locale refusé. Un contrôle qui ne couvre que le premier cas laisse parfois passer le paquet local, ce qui revient à verrouiller l’entrée principale en gardant une trappe sous le tapis.

Exploitation : mises à jour, supervision et retrait d’urgence

L’inventaire doit remonter au minimum l’identifiant, la version, l’état d’activation, les permissions déclarées et le navigateur concerné. Ces données alimentent la supervision de parc et la réponse à incident. Un inventaire de logiciels qui ne distingue pas les extensions est incomplet pour les postes exposés aux applications web.

Surveiller les changements de version et les écarts de politique. Une extension désactivée localement mais toujours autorisée dans la politique reste une dette. À l’inverse, retirer l’autorisation centrale empêche les installations futures, mais le comportement exact d’une extension déjà présente dépend du navigateur et du mode de gestion. Tester la révocation est obligatoire : le retrait doit désactiver ou désinstaller l’extension existante, puis être vérifié sur un échantillon de postes.

Prévoir une procédure de retrait d’urgence avec une modification de politique distribuable sans intervention locale. Le retrait doit inclure la révocation des sessions à risque lorsque l’extension pouvait lire ou modifier des pages authentifiées. Supprimer le paquet ne retire pas les données déjà exfiltrées, ni les actions déjà réalisées. La sécurité n’a pas de bouton annuler, seulement des journaux, des hypothèses et du café froid.

Les extensions n’ont généralement pas de secret d’entreprise à sauvegarder. En revanche, les paramètres distribués, les listes d’autorisation et les preuves de revue doivent être versionnés dans un dépôt avec contrôle d’accès et validation. Les mêmes pratiques que pour la gestion du code et des pipelines s’appliquent : revue à deux paires d’yeux, historique des changements, test avant diffusion, retour arrière documenté.

🐝 Ce qui arrive si on s’en passe

Sans politique d’extensions gérée, le périmètre réel des postes devient la somme des choix individuels : toute extension du magasin s’installe avec les permissions qu’elle réclame, et la synchronisation du profil navigateur peut réimporter sur le poste professionnel une extension ajoutée depuis un appareil personnel connecté au même compte. Le mode développeur reste ouvert, ce qui permet de charger un paquet non empaqueté qui n’a transité par aucun magasin. Côté détection, le trafic émis par une extension part du processus du navigateur, souvent vers des domaines d’apparence banale ; sans inventaire des extensions, ni l’outil de protection du poste ni le proxy ne permettent d’attribuer ce trafic à un composant précis. Lors d’un incident, il devient alors impossible de délimiter les postes et les sessions exposés, donc de cibler les révocations.

🦫 Explication de la marmotte 🍫

Une extension est un programme ajouté au navigateur. Elle reçoit des autorisations au moment de son installation. Selon ces autorisations, elle peut voir les pages ouvertes, modifier leur contenu, observer ce qui est saisi ou communiquer avec un programme installé sur le poste. Certaines extensions ont besoin de droits larges pour leur fonction, mais ces droits restent disponibles lors des versions suivantes.

Le navigateur télécharge régulièrement les nouvelles versions depuis une boutique ou un serveur déclaré par l’éditeur. Si l’éditeur est racheté, piraté ou décide de changer son produit, une nouvelle version peut utiliser les autorisations déjà accordées pour collecter des informations ou modifier une page. Les sessions déjà ouvertes dans les applications de travail sont particulièrement visées, car elles donnent accès sans demander à nouveau le mot de passe.

L’entreprise doit donc empêcher l’installation libre et garder une liste limitée d’extensions autorisées. Cette liste doit préciser qui est responsable, quels droits sont demandés et pourquoi. Les règles sont envoyées automatiquement aux navigateurs gérés. Elles bloquent les extensions inconnues et peuvent retirer rapidement une extension devenue dangereuse.

Ce retrait ne répare pas ce qui a déjà été lu ou envoyé. Il faut alors examiner les journaux, couper les sessions exposées et vérifier les actions sensibles. Les applications doivent aussi demander une nouvelle preuve d’identité pour les opérations critiques, car le navigateur seul ne peut pas empêcher tous les abus.

À lire aussi

• Comment sécuriser les jetons stockés sur mobilePourquoi le chiffrement de partition ne protège pas suffisamment les jetons et caches sensibles sur un appareil mobile, et comment exploiter Keychain iOS et Keystore Android.
• Durcir les postes de développeurs contre le vol de code et secretsLes postes de développeurs constituent une cible souvent oubliée du durcissement, alors qu’ils concentrent code source, identités, secrets et accès de production.
• Pourquoi un certificat diffère selon le navigateurComparatif des magasins de confiance des navigateurs et des autorités racines selon les plateformes.
• Comment sécuriser Redis et Memcached distribuésArchitecture de mise en cache distribuée sécurisée avec Redis et Memcached, exposition réseau, authentification, empoisonnement et exploitation.

Pages voisines

La citent

• Pourquoi les équipes contournent la sécurité officielle

Politique de sécurité des extensions navigateur en entreprise

Elle cite

• ⇄Lien dans les deux sens :Attributs du cookie de session
• ⇄Lien dans les deux sens :Extensions de navigateur IA, permissions et contrôle en entreprise
• Déployer FIDO2 pour comptes à privilèges
• Intégration continue avec Git : automatiser vos workflows

⇄ : les deux pages se citent l’une l’autre.