Ressources · 19
Évaluer les extensions de navigateur avant leur déploiement
Examiner les permissions, les accès aux sites, les mises à jour et la capacité de retrait.
· 14 min
Ce que ce guide permet
- Inventorier les extensions
- Qualifier les permissions
- Maîtriser les mises à jour
- Préparer le retrait
Contrôle express
- Quel besoin précis justifie cette extension ?
- À quels sites et données peut-elle accéder ?
- Les permissions sont-elles proportionnées ?
- Qui surveille les nouvelles versions ?
- Comment la désactiver sur tous les postes concernés ?
Méthode pas à pas
- 01
Recenser les usages
Rassemblez les extensions installées, leurs identifiants, versions, navigateurs, utilisateurs, équipes et propriétaires. Identifiez les doublons et les usages sans responsable.
Livrable : registre daté des extensions et de leurs propriétaires.
- 02
Décrire le besoin
Associez chaque extension à une tâche réelle et aux alternatives disponibles. Définissez les données consultées et les sites concernés avant de juger les permissions.
Livrable : fiche de besoin et de périmètre.
- 03
Examiner les accès
Lisez le manifeste et les avertissements : accès aux hôtes, onglets, stockage, presse-papiers et autres capacités demandées. Distinguez permissions permanentes et optionnelles.
Livrable : grille de permissions justifiées ou à réduire.
- 04
Vérifier l’éditeur et les changements
Documentez l’éditeur, la source de distribution, la politique de confidentialité et les modifications de version. Une présence dans une boutique ne remplace pas cette revue.
Livrable : dossier de provenance et règle de réévaluation.
- 05
Déployer sous contrôle
Testez l’extension avec un profil et des données adaptés, puis définissez une liste approuvée ou des règles de blocage selon le navigateur administré.
Livrable : décision, paramètres de déploiement et responsable.
- 06
Préparer la sortie
Prévoyez le retrait rapide, la désactivation, la recherche des postes concernés et le traitement des données éventuellement exposées si un incident survient.
Livrable : procédure de retrait testée.
Comprendre · essayer · décider
Lire les permissions à partir de la tâche réelle
Pour une extension Chrome Manifest V3, séparez la capacité technique demandée, les sites concernés et le moment où l’accès est accordé. Le nombre de permissions ne constitue pas un score de sécurité : une seule autorisation large peut exposer davantage de pages que plusieurs capacités limitées.
Une action ponctuelle sur la page choisie par la personne peut parfois utiliser activeTab plutôt qu’un accès permanent à tous les sites. Cette permission temporaire suit un geste explicite ; elle peut rester accordée lors d’une navigation dans la même origine, puis être révoquée lors d’un changement d’origine ou de la fermeture de l’onglet. Les pages restreintes du navigateur restent exclues.
Pour injecter un script avec l’API scripting, la permission scripting et un accès approprié à la page sont nécessaires. Examinez aussi les scripts déclarés dans content_scripts.matches : leurs accès ne se résument pas à la liste permissions. Vérifiez la version réellement installée et les réglages du navigateur administré, puis comparez le comportement observé au besoin validé.
Repères et preuves à conserver
| Repère | Ce que vous pouvez conclure | Preuve à conserver |
|---|---|---|
| Capacité | scripting décrit une capacité d’injection, sans autoriser seul l’accès à tous les sites. | API utilisée, fonction attendue et accès à la page associé. |
| Périmètre | host_permissions et content_scripts.matches peuvent élargir les sites concernés. | Motifs d’hôtes et scripts automatiques examinés séparément. |
| Déclenchement | activeTab correspond à un accès temporaire après une invocation par la personne. | Geste attendu, origine concernée et comportement après navigation. |
| Évolution | Une décision sur une version ne vaut pas pour tous ses changements futurs. | Identifiant, version, éditeur, permissions et date de revue. |
Du constat à la décision
- Décrire la tâche
- Relier capacités et sites
- Tester les limites
- Décider et revoir
Trois périmètres pour une même demande
Les domaines en .test sont fictifs. Les options servent à comparer la justification des accès, pas à déclarer une extension sûre sur son seul manifeste.
- Périmètre justifié
- 12 / 20Extensions du parc fictif avec besoin, accès et propriétaire documentés.
- Revue nécessaire
- 6 / 20La justification ou un contrôle reste incomplet.
- Retrait proposé
- 2 / 20Usage abandonné ou accès non justifié dans ce scénario.
- 60 / 100 · Périmètre justifié
- 30 / 100 · Revue nécessaire
- 10 / 100 · Retrait proposé
12/20 = 60 %, 6/20 = 30 %, 2/20 = 10 %. Les catégories sont exclusives dans cet exemple et totalisent 100 %. Elles décrivent une revue interne, pas un taux de sécurité.
| Option | Déclaration à examiner | Déclenchement et portée | Contrôle utile |
|---|---|---|---|
| A — Page choisie | activeTab + scripting ; aucun hôte permanent ni script automatique dans cet exemple | Invocation explicite ; accès temporaire lié à l’origine de la page | Essayer une autre origine et une page restreinte ; vérifier que l’extension respecte la limite. |
| B — Site documentaire | scripting + host_permissions sur https://docs.example.test/* | Accès à l’hôte déclaré ; pas nécessairement limité à un clic | Justifier le besoin sur ce site et examiner les traitements en arrière-plan. |
| C — Tous les sites | host_permissions et content_scripts.matches sur <all_urls> | Périmètre très large ; scripts automatiques selon leurs déclarations | Demander pourquoi A ou B ne suffisent pas et tester les sites exclus du besoin. |
Une déclaration d’accès n’établit pas, à elle seule, ce que le code fait des données. Ces exemples ne sont pas des manifestes complets à installer.
Peut-on garder l’accès après une navigation dans la même origine ?
Oui : activeTab peut rester accordée sur la même origine. Le test doit distinguer cette navigation d’un changement d’origine ; temporaire ne signifie pas automatiquement « une seule page pour toujours ».
Deux permissions valent-elles un risque deux fois plus élevé ?
Non. Reliez capacités, hôtes, déclenchement, code et données. Compter les noms de permissions ne mesure ni l’impact ni la probabilité d’un abus.
Contrôles avant de conclure
- Relier chaque accès à une fonction nécessaire et à un propriétaire.
- Examiner les hôtes, les scripts automatiques et les réglages administrés.
- Tester avec des données fictives, puis revoir tout changement important de périmètre.
- Vérifier le retrait sur les postes concernés et traiter séparément les données déjà transmises.
Décision : retenir le plus petit accès compatible avec la tâche vérifiée, documenter les exceptions et fixer les événements qui imposent une nouvelle revue.
Changer une hypothèse
Une tâche ponctuelle justifie-t-elle un accès permanent ?
Une extension fictive doit reformater le texte de la page active à la demande. Ce besoin sert de point de comparaison pour examiner ses accès.
- Tâche
Agir sur une page choisie après une action explicite de l’utilisateur.
- Permission
Examiner la possibilité d’un accès temporaire avec activeTab et les API nécessaires.
- Écart
Demander ce qui justifie un accès à tous les sites si la tâche reste ponctuelle.
Exercice de lecture : les variantes décrivent des situations fictives.
activeTab garantit-il l’innocuité de l’extension ?
- Nouvel élément
- L’accès est plus limité dans le temps, mais du code s’exécute toujours avec les capacités autorisées.
- Ce que cela change
- Examiner aussi l’éditeur, la fonction, les flux de données et les mises à jour. Une permission plus étroite réduit un périmètre ; elle ne certifie pas le logiciel.
Et si l’extension doit fonctionner en arrière-plan ?
- Nouvel élément
- Le besoin annoncé devient une surveillance continue de plusieurs domaines.
- Ce que cela change
- Réévaluer la nécessité, les domaines visés et la politique de données. Ce nouveau besoin ne doit pas être présenté comme identique à l’action ponctuelle initiale.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture | Extensions avec propriétaire et usage documentés | Traiter les installations sans responsable |
| Accès justifiés | Permissions reliées à une fonction nécessaire | Réduire ou refuser les accès trop larges |
| Changements suivis | Versions importantes revues avant généralisation | Suspendre une mise à jour risquée |
| Retrait vérifié | Postes couverts par un test de désactivation | Corriger la diffusion et les exceptions |
Erreurs fréquentes
- Confondre présence dans une boutique et validation de sécurité
- Accepter un accès à tous les sites sans justification
- Oublier les extensions installées dans des profils personnels
- Ne pas revoir les permissions après mise à jour
Questions fréquentes
Une extension populaire est-elle sûre ?
La popularité ne renseigne pas sur les permissions nécessaires à votre usage, les données accessibles ni les changements futurs.
Faut-il interdire toutes les extensions ?
Une politique proportionnée permet de choisir selon le besoin, les accès et le contexte du navigateur administré.
Quand réévaluer ?
Lors d’un changement de permissions, de propriétaire, de fonction ou de version importante, et lors des revues régulières du parc.
Extensions : permissions et accès
Lire un manifeste aide à préparer une revue d’extension : quelles API sont demandées, pour quels sites, et à quel moment ? La déclaration décrit un périmètre demandé. Les accès effectifs dépendent aussi des autorisations accordées, des réglages du navigateur, des stratégies et du code exécuté.
Sélection éditoriale de 20 permissions Chrome, noms vérifiés dans la documentation officielle le 23 octobre 2026. Les capacités et questions sont une synthèse CIE. Ce répertoire n’est ni la liste complète des permissions ni une échelle officielle de risque ; il ne s’applique pas automatiquement à Firefox ou à toutes les versions d’Edge.
Cinq déclarations à ne pas confondre
| Champ du manifeste | Ce qu’il déclare | Question de revue CIE |
|---|---|---|
| permissions | Permissions d’API requises. | Quelle fonction justifie chaque capacité ? L’absence d’avertissement ne signifie pas absence d’accès. |
| optional_permissions | Permissions d’API pouvant être demandées à l’exécution, selon les restrictions de l’API. | Quelles permissions ont été effectivement accordées et peut-on retirer la fonction optionnelle ? |
| host_permissions | Motifs d’hôtes demandés pour les capacités qui les utilisent. | Peut-on restreindre les hôtes ? Pour ce champ, le chemin n’est pas une restriction de répertoire. |
| optional_host_permissions | Périmètre dans lequel des accès d’hôtes peuvent être demandés à l’exécution. | La portée déclarée n’est pas une liste des sites déjà autorisés. |
| content_scripts.matches | Motifs utilisés pour les scripts de contenu statiques. | Lire aussi exclusions, globs et options de frames ; ce champ est distinct des injections programmatiques. |
Google Chrome · Declare permissions · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Google Chrome · Permissions API · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
20 permissions : capacités et preuves à examiner
Google Chrome · Permissions · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Hôtes, chemins et contexte : cinq repères
| Déclaration ou mécanisme | Lecture utile | Limite à conserver |
|---|---|---|
| host_permissions : https://intranet.example.org/private/* | Le chemin figure dans le motif mais est ignoré pour les permissions d’hôtes. | Ne pas promettre un accès limité au répertoire /private/ à partir de cette seule ligne. |
| content_scripts.matches + exclude_matches | Les conditions d’injection de scripts statiques combinent inclusions et exclusions. | Des scripts peuvent aussi être enregistrés ou injectés par le code ; ce lecteur n’évalue pas ces conditions. |
| *://*.example.org/* | Le joker de schéma vise HTTP et HTTPS ; le motif inclut l’hôte de base et ses sous-domaines. | Ne pas confondre motif d’extension et syntaxe des stratégies administratives. |
| <all_urls> | Portée sur les schémas autorisés, avec les restrictions propres au navigateur. | La déclaration ne démontre pas que toutes les pages, les fichiers locaux ou la navigation privée sont accessibles. |
| activeTab et file:///* | activeTab dépend d’une invocation ; les URL file nécessitent un accès accordé dans les réglages. | Tester le contexte réel. Ni le manifeste ni ce lecteur ne montrent les choix effectués dans le profil. |
Google Chrome · Match patterns · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Google Chrome · activeTab · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Google Chrome · Content scripts · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Lecteur local de manifeste V3
Collez un manifeste JSON Manifest V3 pour inventorier permissions et déclarations de sites. Le traitement reste dans cette page : aucune installation, requête aux sites, conservation locale, transmission du texte ou export. Les exemples sont fictifs et servent à lire les résultats.
Lecture bornée à 64 Kio UTF-8, 200 déclarations, 20 blocs content_scripts et 2 048 caractères par valeur. Ce lecteur examine les quatre listes de permissions ainsi que matches et exclude_matches des scripts statiques. Il conserve chaque occurrence avec son chemin. Il ne valide pas la syntaxe des motifs, les règles de Chrome, les avertissements d’installation, les globs, les frames, les fichiers de code, les règles réseau, les jetons OAuth, les stratégies ni les accès accordés. Une clé de premier niveau hors périmètre est signalée sans lire sa valeur ; un JSON accepté ici peut être refusé par Chrome. En cas de clé JSON répétée, JSON.parse conserve la dernière valeur ; revoir le fichier d’origine pour lever toute ambiguïté.
Permissions d’API déclarées
| Emplacement | Permission déclarée | Repère documentaire |
|---|
Déclarations de sites
| Emplacement | Valeur déclarée | Repère de lecture |
|---|
Clés hors périmètre
Huit exemples à lire aussi sans JavaScript
Action ponctuelle sur l’onglet
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": [
"activeTab",
"scripting",
"storage"
]
}Trois permissions d’API, aucune liste d’hôtes. activeTab peut fournir un accès temporaire après invocation ; il faut examiner le geste et le code. L’absence de liste d’hôtes ne prouve pas l’absence d’accès.
Cookies et requêtes sur une large portée
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": [
"cookies",
"webRequest"
],
"host_permissions": [
"<all_urls>"
]
}Deux permissions d’API et une déclaration <all_urls>. Examiner les permissions d’hôtes, les opérations et les restrictions réelles. webRequest n’est pas synonyme de webRequestBlocking.
Capacités optionnelles
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": [
"storage"
],
"optional_permissions": [
"history"
],
"optional_host_permissions": [
"https://*/*"
]
}Une permission requise, une permission optionnelle et une déclaration d’hôtes optionnelle. Ce sont des demandes possibles, pas la preuve que history et tous les hôtes HTTPS sont déjà accordés.
Script statique avec une exclusion
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"content_scripts": [
{
"matches": [
"https://*.example.org/*"
],
"exclude_matches": [
"https://private.example.org/*"
],
"js": [
"content.js"
],
"run_at": "document_idle"
}
]
}Un matches et un exclude_matches dans le même bloc. Les deux lignes sont affichées sans soustraction automatique. js et run_at ne sont pas analysés ; la portée effective exige une revue du script et des conditions d’injection.
Permission hors sélection et chemin trompeur
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": [
"alarms"
],
"host_permissions": [
"https://intranet.example.org/private/*"
]
}alarms n’appartient pas aux 20 noms de cette sélection : son absence du répertoire ne signifie pas permission inconnue de Chrome. Le chemin /private/* dans host_permissions ne limite pas l’accès à ce répertoire.
Identité et composant natif : hors périmètre visible
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": [
"identity",
"nativeMessaging"
],
"background": {
"service_worker": "worker.js"
},
"oauth2": {
"client_id": "fictional.apps.example.invalid",
"scopes": [
"fictional-scope"
]
},
"externally_connectable": {
"matches": [
"https://portal.example.org/*"
]
}
}Deux permissions connues ; background, oauth2 et externally_connectable sont signalées comme clés de premier niveau hors périmètre. Le lecteur ne prouve rien sur les scopes, le code du service worker ou les correspondants natifs.
Type de champ incorrect
{
"manifest_version": 3,
"name": "CIE fictional review example",
"version": "1.0.0",
"permissions": "tabs"
}permissions doit être une liste de chaînes pour ce lecteur. Aucun résultat partiel n’est conservé quand le type est incorrect.
Manifest V2 : lecture non prise en charge
{
"manifest_version": 2,
"name": "CIE fictional legacy example",
"version": "1.0.0",
"permissions": [
"https://*/*",
"tabs"
]
}La version 2 est explicitement refusée. Ses anciennes déclarations d’hôtes ne sont pas réinterprétées comme un manifeste V3. Aucun verdict de compatibilité du navigateur n’est produit.
Transformer la lecture en décision vérifiable
- Fixer le besoin et le périmètre
Noter identifiant d’extension, éditeur, source de distribution, version, navigateur et poste de test. Relier chaque capacité à une tâche et aux données concernées.
- Comparer demandé, accordé et observé
Relever le manifeste, les choix d’accès du profil et les stratégies appliquées, puis observer les gestes et flux sur des données de test. Ces trois niveaux ne sont pas interchangeables.
- Rejouer après changement
Comparer les versions, permissions, hôtes, règles et composants natifs. Les avertissements d’installation dépendent des combinaisons de permissions ; leur nombre ne forme pas un score de sécurité.
- Tester restriction et retrait
Sur Edge administré, une permission bloquée peut désactiver une extension sans la supprimer. Vérifier la portée de la stratégie et le retrait séparé des composants natifs et données externes. Conserver une preuve de l’état final.
Google Chrome · Permission warning guidelines · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent
Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23
Repères techniques : Google Chrome for Developers et Microsoft Learn, liens officiels ci-dessous et à chaque permission. Documentation Google sous CC BY 4.0 sauf mention contraire ; les descriptions et questions ci-dessus sont une synthèse éditoriale CIE adaptée au français et à l’anglais. Les exemples fictifs sont originaux. Cette page ne constitue pas une validation de Google ou Microsoft.
Google Developers · Site policies · Documentation attribution and reuse conditions
Creative Commons Attribution 4.0
Source documentaire vérifiée
Chrome permissions · 2026-10-23
Source HTML SHA-256: 0d8d9b108def74b5a47c392b5c9018ed0bf6b3e02a12315a95b31e7e753c5166
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
- Chrome Extensions — déclaration des permissions
- Microsoft Edge — gestion des extensions par stratégie
- Google Chrome · Permissions
- Google Chrome · Permissions API
- Google Chrome · activeTab
- Google Chrome · Match patterns
- Google Chrome · Content scripts
- Google Chrome · Permission warning guidelines
- Google Chrome · Stay secure
- Google Developers · Site policies
