Extensions de navigateur IA, permissions et contrôle en entreprise

Une extension de navigateur qui promet de « résumer cette page avec l’intelligence artificielle (IA) » demande presque toujours le droit de lire toutes les pages visitées, et envoie ce qu’elle lit à un serveur que l’organisation n’a jamais évalué. Le chiffrement du trafic n’y change rien : l’extension lit la page après déchiffrement, là où aucun équipement réseau ne regarde. Le sujet ici : ce que ces permissions ouvrent, comment elles se retournent, et quelle politique de contrôle tient en entreprise.

→ Lire l’explication complète de la marmotte

Permissions d’une extension IA : lire toutes les pages

Sous Manifest V3, le format actuel des extensions Chrome et Edge, l’accès aux pages se déclare par host_permissions et par les motifs matches des scripts de contenu. Une valeur <all_urls> ou *://*/* donne à l’extension le document complet de chaque onglet : webmail, console d’administration cloud, outil de gestion de la relation client, intranet. Elle lit le texte affiché, les champs de formulaire, et avec cookies elle peut atteindre les jetons de session des sites concernés.

Le fonctionnement type d’une extension IA ajoute un maillon : le texte de la page part vers le serveur de l’éditeur, qui le transmet à un fournisseur de modèle. Deux tiers reçoivent donc le contenu, et c’est celui qui n’a signé aucun contrat avec l’organisation qui voit tout en premier.

La permission activeTab est l’alternative raisonnable : l’accès n’est accordé qu’à l’onglet courant, et seulement après un geste explicite de l’utilisateur (clic sur l’icône, raccourci). Position : une extension IA qui exige <all_urls> pour une fonction déclenchée à la demande est refusée, car activeTab suffit techniquement à ce cas d’usage. Les autres permissions à examiner de près : scripting, tabs, clipboardRead, webRequest, debugger et nativeMessaging, cette dernière ouvrant un canal vers un programme installé sur le poste.

Surface d’attaque : mise à jour silencieuse, rachat, imitation

La validation d’une extension porte sur une version ; le magasin en pousse d’autres sans demander. Une élévation de permissions déclenche en principe une nouvelle demande d’accord et la désactivation de l’extension en attendant ; une modification du code à permissions constantes, non. Une extension qui détient déjà <all_urls> peut donc devenir malveillante par une banale mise à jour, sans le moindre signal côté utilisateur. Le rachat d’extensions populaires par des acteurs qui monétisent ensuite la base installée est un schéma récurrent : la note de cinq étoiles, elle, reste attachée à l’ancien propriétaire.

Deuxième vecteur, l’imitation. La vague des assistants a produit une abondance d’extensions dont le nom et l’icône évoquent un assistant connu sans lien avec son éditeur, et dont la fonction réelle est la collecte de sessions ou de contenus. Le magasin officiel n’est pas une certification ; c’est un catalogue.

Troisième vecteur, propre aux extensions qui agissent (remplir un formulaire, cliquer, envoyer) : le contenu d’une page visitée peut contenir des instructions cachées que le modèle exécute avec les droits de l’extension. Plus l’extension a de pouvoir, plus une page piégée en récupère.

Ce que le chiffrement TLS (Transport Layer Security) et l’inspection réseau ne garantissent pas : ils voient au mieux ce que l’extension envoie vers son serveur, jamais ce qu’elle a lu. La prévention de fuite au niveau du proxy ne rattrape que le trafic qu’elle sait déchiffrer et interpréter.

Politique de contrôle des extensions en entreprise

Deux modèles s’affrontent : liste de blocage (tout est permis sauf ce qui est connu comme mauvais) et liste d’autorisation (tout est bloqué sauf ce qui est validé). Le compromis : la liste d’autorisation coûte un circuit de demande et quelques frustrations ; la liste de blocage coûte une course perdue d’avance contre un magasin qui publie plus vite qu’une équipe sécurité ne lit. Position : liste d’autorisation, avec un catalogue interne publié pour que la demande ait un chemin.

Critères de validation d’une extension IA : permissions minimales (activeTab plutôt que <all_urls>), éditeur identifié, destination des données documentée, existence d’une offre avec engagements contractuels. Chaque extension validée reçoit sa propre entrée dans la politique, indexée par son identifiant de 32 caractères, et runtime_blocked_hosts lui interdit les domaines sensibles même si elle est autorisée. D’après la documentation de la règle ExtensionSettings (à vérifier sur la version déployée), une entrée individuelle n’hérite pas des réglages de l’entrée * : les hôtes bloqués doivent y être répétés.

Ce que la politique ne garantit pas : elle ne couvre que les navigateurs gérés. Un second navigateur installé par l’utilisateur, un navigateur portable ou un profil non géré échappe à tout. Le contrôle des applications sur le poste et l’inventaire des navigateurs sont les prérequis, pas des options. Côté exploitation, l’inventaire des identifiants d’extensions installées se collecte régulièrement, toute nouvelle apparition déclenche une alerte, et la liste validée se revoit à chaque changement de propriétaire ou de permissions annoncé. Les questions d’identité et de session liées au navigateur relèvent de Identités, accès et habilitations, et le durcissement du poste de la rubrique Cloud, plateformes et exploitation.

Exemple : politique Chrome et inventaire sous Linux

La politique ci-dessous bloque toute extension non explicitement validée et fixe des limites par défaut ; l’inventaire liste les permissions réellement accordées dans un profil.

# Politique machine de Google Chrome sous Linux
# (Chromium lit /etc/chromium/policies/managed/)
sudo mkdir -p /etc/opt/chrome/policies/managed
sudo tee /etc/opt/chrome/policies/managed/extensions.json >/dev/null <<'EOF'
{
  "ExtensionSettings": {
    "*": {
      "installation_mode": "blocked",
      "blocked_permissions": ["debugger", "nativeMessaging", "clipboardRead"],
      "runtime_blocked_hosts": ["*://*.intranet.example", "*://console.example.com"],
      "blocked_install_message": "Extension non validée : passer par le catalogue interne."
    }
  }
}
EOF
# Contrôle : ouvrir chrome://policy puis « Recharger les règles »

# Inventaire : nom, permissions d'API et accès aux sites de chaque extension
# (un nom de la forme __MSG_xxx__ est localisé : se fier alors à l'identifiant)
for m in ~/.config/google-chrome/Default/Extensions/*/*/manifest.json; do
  jq -c '{nom: .name,
          perms: (.permissions // []),
          hotes: ((.host_permissions // []) + [.content_scripts[]?.matches[]?])}' "$m"
done

Une ligne dont le champ hotes contient <all_urls> ou *://*/* désigne une extension qui lit tout ; c’est la première à justifier ou à retirer.

🐝 Ce qui arrive si on s’en passe

Sans contrôle des extensions, une extension qui lit toutes les pages lit aussi l’interface web de l’assistant d’IA que l’organisation a contractualisé. Les conversations de l’espace entreprise, protégées par un contrat, une rétention négociée et une authentification unique, s’affichent dans un onglet comme n’importe quelle page, et partent vers le serveur de l’extension en dehors de tout engagement. Les garanties achetées avec l’abonnement entreprise ne couvrent que le chemin entre le navigateur et le fournisseur ; elles ne disent rien d’un tiers installé dans le navigateur lui-même, et les journaux d’audit de l’assistant n’en gardent aucune trace.

🦫 Explication de la marmotte 🍫

Une extension est un petit programme ajouté au navigateur. Au moment de l’installation, elle demande des droits, et beaucoup d’extensions qui promettent de résumer ou de traduire une page avec l’intelligence artificielle demandent le droit de lire toutes les pages visitées, sans exception. Dès lors, elle voit la messagerie, les outils internes de l’entreprise et les pages d’administration, et elle envoie ce texte à son propre serveur, qui le transmet souvent à un autre service. Ce qui passe sur le réseau est chiffré, mais l’extension lit la page une fois qu’elle est déjà déchiffrée et affichée, donc les outils de surveillance du réseau ne voient pas ce qu’elle a lu. Le danger augmente avec le temps : l’extension se met à jour toute seule, peut changer de propriétaire et devenir malveillante sans nouvelle demande d’autorisation. Pour s’en protéger, l’entreprise bloque par défaut toutes les extensions dans les navigateurs qu’elle gère, puis autorise une à une celles qu’elle a vérifiées, en leur interdisant les sites sensibles. Elle doit aussi empêcher l’usage de navigateurs non gérés, sinon la règle ne s’applique pas, et surveiller la liste des extensions présentes sur les postes.

Pages voisines

La citent

Extensions de navigateur IA, permissions et contrôle en entreprise

Elle cite

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

Extensions de navigateur IA, permissions et contrôle en entreprise

Extensions de navigateur IA, permissions et contrôle en entreprise

Permissions d’une extension IA : lire toutes les pages

Surface d’attaque : mise à jour silencieuse, rachat, imitation

Politique de contrôle des extensions en entreprise

Exemple : politique Chrome et inventaire sous Linux

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines