Chrome 155 : sécuriser les extensions sur postes gérés

Chrome 155 durcit l’accès de certaines extensions à l’API chrome.debugger lorsqu’un navigateur est administré par une organisation. Dès qu’une politique limite les hôtes, interdit les captures d’écran ou applique des règles de prévention des fuites de données, l’attachement au protocole DevTools est refusé pour l’ensemble des cibles. Pour une équipe produit, le sujet n’est pas de contourner cette décision : c’est d’identifier les outils internes concernés et de prévoir une expérience explicite pour les utilisateurs gérés.

Pourquoi Chrome bloque tout l’accès, plutôt qu’un seul site

L’API chrome.debugger donne un accès direct au Chrome DevTools Protocol. Elle peut notamment évaluer du code ou intercepter du trafic réseau. Ce niveau de contrôle se situe sous le modèle d’origine habituel du Web : une liste d’hôtes autorisés ou bloqués ne permet donc pas de le restreindre de façon fiable page par page.

À partir de Chrome 155, Chrome vérifie les politiques au moment de chrome.debugger.attach(). Une extension configurée avec une liste d’hôtes bloqués, même si certains hôtes sont autorisés, ne pourra plus s’y attacher. La même logique s’applique si les captures sont désactivées ou si des règles DLP sont actives. Les navigateurs personnels et les environnements gérés sans ces règles précises ne sont pas concernés.

Cartographier les extensions réellement exposées

Commencez par inventorier les extensions distribuées par l’entreprise et celles approuvées pour les équipes. Recherchez la permission debugger, puis les appels à chrome.debugger.attach(). Un outil de support, d’automatisation QA ou d’inspection de pages peut dépendre de cette API sans que le risque soit visible dans son interface.

Tester le vrai contexte administré

Un test sur le poste d’un développeur ne suffit pas. Préparez un profil de recette avec les politiques d’hôtes, de captures et DLP représentatives de la production. Vérifiez l’ouverture d’onglet, les fonctions d’analyse, les messages d’erreur et le comportement après une mise à jour de politique. Chrome annonce une arrivée en stable le 6 octobre 2026 ; la bêta est disponible depuis le 16 septembre.

Remplacer l’accès bas niveau quand il n’est pas indispensable

Une extension qui n’a besoin que d’injecter un script dans des pages autorisées peut souvent utiliser chrome.scripting. Pour des règles réseau déclaratives, chrome.declarativeNetRequest est plus adapté. L’accès aux cookies reste possible avec chrome.cookies et les permissions d’hôte usuelles. Ces API ne remplacent pas chaque usage du protocole DevTools, mais elles permettent une autorisation plus granulaire et plus cohérente avec les listes d’entreprise.

Si l’accès chrome.debugger demeure nécessaire, le bon arbitrage se fait avec l’administrateur : quelles extensions ont besoin de cette capacité, sur quels postes et avec quelles protections compensatoires ? Une liste d’hôtes bloqués ne peut pas coexister avec cet accès sur la même extension. La dérogation doit être documentée, limitée et revue, plutôt que masquée par un échec technique.

Rendre le blocage compréhensible dans le produit

1. Intercepter le refus d’attachement. Affichez une explication utile, sans prétendre qu’il s’agit d’une panne de l’utilisateur.
2. Distinguer les cas. Chrome renvoie des erreurs différentes pour une restriction d’hôtes et une restriction de capture ou DLP ; consignez-les sans capturer de données sensibles.
3. Prévoir un parcours de repli. Gardez les fonctions ne nécessitant pas le protocole DevTools et orientez l’utilisateur vers son équipe informatique lorsque cela est nécessaire.
4. Mesurer la migration. Suivez le nombre de refus et le recours aux alternatives avant de retirer une ancienne implémentation.

Une contrainte de sécurité à transformer en contrat clair

Ce changement rappelle qu’une extension métier fait partie du système d’information, pas seulement du navigateur. Clarifier les permissions, les politiques et les voies de repli réduit les surprises lors d’un déploiement administré. La publication officielle de Chrome, mise à jour le 16 septembre 2026, détaille les règles concernées, les erreurs retournées et la période de transition annoncée.