Dossier technique
Une extension VPN ne se juge pas seulement sur son interface, sa promesse commerciale ou son changement d’IP apparent. Elle se juge aussi sur le périmètre d’accès qu’elle déclare dans son manifeste. Dans Chromium, le modèle de permissions est une surface de confiance explicite : APIs demandées, accès hôtes, permissions optionnelles, avertissements affichés à l’utilisateur, et écart éventuel entre ce qui est annoncé et ce qui est techniquement requis.
Une extension Chromium fonctionne dans un modèle de permissions déclarées. Ce modèle n’est pas décoratif. Il borne les APIs utilisables, le périmètre des hôtes accessibles, la capacité à lire ou modifier certaines données et le type d’avertissements que l’utilisateur verra avant ou pendant l’usage. Pour une extension VPN, cette couche est centrale : c’est elle qui permet de distinguer un simple discours de confidentialité d’une surface d’accès effectivement accordée par le navigateur.
Le premier réflexe technique ne doit donc pas être “quelle marque l’éditeur affiche”, mais “quelles permissions l’extension demande-t-elle, et pourquoi ?”. Tant qu’on ne lit pas cela, on ne lit pas réellement le produit.
Le modèle de permissions n’est pas un détail d’implémentation
Dans Chromium, la logique de permissions sert à limiter ce qu’une extension peut faire si elle est compromise, mal conçue ou plus invasive que prévu. Le navigateur ne traite donc pas la déclaration de permissions comme un simple inventaire fonctionnel. Il s’en sert aussi pour matérialiser une relation de confiance avec l’utilisateur.
Pour une extension VPN, ce point est encore plus important que pour une extension cosmétique ou de productivité. Une extension orientée réseau ou confidentialité risque d’être perçue comme un outil protecteur par nature. Or cette perception ne vaut rien si la surface d’accès demandée est excessivement large, mal justifiée ou incohérente avec le périmètre annoncé.
C’est ici que la page Extension VPN vs application VPN doit rester en arrière-plan : une extension n’opère déjà que dans le périmètre du navigateur. Ses permissions déterminent ensuite ce qu’elle peut réellement voir, contrôler ou modifier dans ce périmètre.
permissions : les capacités API demandées par l’extension
Le champ permissions sert à déclarer des capacités liées aux APIs d’extension. Il
ne décrit pas seulement un besoin abstrait ; il ouvre l’accès à des familles de fonctions
précises. Quand une extension VPN demande une permission, elle ne réclame pas une faveur
symbolique : elle étend son pouvoir d’action à l’intérieur du navigateur.
Une lecture sérieuse consiste donc à relier chaque permission à une conséquence technique. Une permission de type réseau, observation de requêtes, script injection ou interaction avancée avec les onglets n’a pas le même poids qu’une permission anodine. Le problème n’est pas de diaboliser la permission, mais d’exiger une justification cohérente avec la fonction réelle de l’extension.
Une extension VPN techniquement défendable peut demander des permissions fortes. Ce n’est pas interdit. En revanche, elle doit permettre de comprendre pourquoi elles sont nécessaires, ce qu’elles ouvrent exactement, et si elles auraient pu être limitées.
host_permissions : le vrai périmètre d’accès aux sites et aux données d’hôte
Le champ host_permissions mérite une lecture séparée. Il ne s’agit pas d’un simple
complément cosmétique aux permissions API. Il détermine le périmètre d’hôtes pour lesquels
certaines APIs sensibles peuvent lire, modifier ou interagir avec les données du site visé.
Dans la pratique, c’est souvent là que l’on mesure la différence entre une extension sobre et
une extension expansive. Une demande ciblée sur un périmètre restreint n’a pas la même portée
qu’un schéma global du type http://*/* ou https://*/*. Plus le motif
est large, plus la surface d’accès l’est aussi.
Pour une extension VPN, ce point est critique. Si l’extension veut lire ou modifier des données liées à des hôtes, intercepter certains flux ou agir sur des onglets correspondant à des sites donnés, la portée de ces motifs doit être lue comme une frontière technique, pas comme une formalité.
permissions et host_permissions ne jouent pas le même rôle
L’erreur classique consiste à mélanger permissions API et permissions d’hôte. Les premières ouvrent l’accès à des mécanismes du navigateur. Les secondes bornent le périmètre d’hôtes sur lequel certaines de ces capacités peuvent effectivement s’exercer. Une extension peut donc avoir une API puissante sans disposer du même rayon d’action sur tous les sites, ou l’inverse.
Cette distinction est décisive pour une extension VPN ou pseudo-VPN. Ce n’est pas parce qu’une capacité technique existe dans le manifeste qu’elle s’appliquera partout. À l’inverse, un périmètre d’hôtes très large combiné à des APIs sensibles peut considérablement étendre la surface de confiance accordée à l’éditeur.
Le bon audit ne lit donc jamais l’un sans l’autre. Il croise les deux.
Permission warnings : ce que Chrome choisit de signaler à l’utilisateur
Certaines permissions déclenchent des avertissements. Ce mécanisme existe parce que toutes les permissions n’ont pas le même niveau d’intrusion ou la même lisibilité. Pour l’utilisateur, ces avertissements matérialisent une partie du risque ; pour l’analyste, ils signalent qu’un pouvoir non trivial est en train d’être accordé à l’extension.
Il faut toutefois rester rigoureux : l’absence d’avertissement spectaculaire ne signifie pas l’absence d’enjeu. Certaines surfaces de risque ne se lisent pas à l’intensité du message affiché. C’est pourquoi un audit sérieux ne se limite jamais aux boîtes de dialogue visibles : il remonte au manifeste et à la logique de fonctionnement réelle.
Une extension VPN qui prétend minimiser sa surface d’accès devrait donc, en principe, chercher à réduire ses permissions permanentes et à justifier clairement celles qui restent.
optional_permissions et optional_host_permissions : réduire la confiance par défaut
Toutes les permissions n’ont pas besoin d’être permanentes. Chromium permet aussi une logique de permissions optionnelles. Techniquement, c’est un signal important de maturité : une extension peut demander moins au départ, puis solliciter un accès supplémentaire uniquement quand une fonctionnalité en a réellement besoin.
Pour une extension VPN, cette approche est souvent plus saine qu’un manifeste maximaliste livré dès l’installation. Une capacité rarement utilisée, un périmètre d’hôte non indispensable au fonctionnement de base, ou une fonction avancée réservée à certains scénarios n’ont pas besoin de gonfler la surface de confiance initiale.
Une extension qui utilise correctement optional_permissions ou
optional_host_permissions envoie donc un meilleur signal qu’une extension qui
réclame tout immédiatement sans hiérarchiser ses besoins.
activeTab n’est pas un substitut universel à un accès hôte large
Dans l’écosystème Chromium, activeTab sert souvent de permission plus contenue pour
interagir avec l’onglet actif dans certaines conditions, sans demander immédiatement un accès
hôte global. Ce mécanisme peut limiter la portée permanente d’une extension.
Pour une extension VPN, cela ne règle pas tout. Une logique de routage, d’observation ou d’action sur un périmètre plus large ne peut pas toujours être remplacée par un simple modèle temporaire lié à l’onglet actif. Mais cette permission reste un bon révélateur d’intention : si une fonction peut être traitée avec un périmètre plus étroit, demander d’emblée un accès global devient plus difficile à justifier.
En audit, il faut donc poser une question simple : ce que l’extension réclame en permanence aurait-il pu être borné plus finement ?
Lecture des onglets, requêtes web et portée effective
Les permissions prennent tout leur sens quand on les rapproche des APIs réellement utilisées. Dès qu’une extension travaille autour des onglets, de l’injection, de l’interception ou de la modification de requêtes, le périmètre réel dépend à la fois des APIs invoquées et des hôtes autorisés.
C’est particulièrement vrai quand l’extension veut lire certaines propriétés sensibles d’un onglet, agir sur les pages visitées ou s’insérer dans le trafic web correspondant à des hôtes donnés. Une lecture superficielle du manifeste manque alors l’essentiel : le pouvoir d’action vient du croisement entre capacité API et portée hôte.
Pour approfondir la partie routage et traitement du trafic, voir Proxy, PAC et routage navigateur. Pour la question de la surface résiduelle de fuite, voir Surface d’exposition restante.
Manifest V3 : séparation plus nette des champs, pas disparition des enjeux
En Manifest V3, les accès hôtes sont traités séparément des permissions API. Cette séparation clarifie la lecture du manifeste, mais elle ne réduit pas mécaniquement le risque. Elle oblige simplement à lire plus proprement ce qui relève des capacités et ce qui relève du périmètre d’application sur les sites.
En d’autres termes, MV3 rend le manifeste plus structuré, pas automatiquement plus sobre. Une extension peut rester très ambitieuse dans sa surface d’accès tout en étant parfaitement conforme au format moderne.
Pour la partie cycle de vie, service workers et implications d’architecture, voir Manifest V3 et service workers.
Comment lire le manifeste d’une extension VPN sans se laisser impressionner
La bonne méthode consiste à partir des besoins réels d’une extension VPN de navigateur, puis à vérifier si le manifeste reste proportionné à ces besoins. Une extension qui promet un contrôle essentiellement centré sur la navigation n’a pas vocation à accumuler sans explication des permissions larges, des motifs d’hôtes globaux et des accès facultatifs transformés en accès permanents.
Il faut ensuite relier chaque permission à une fonction vérifiable. Si l’extension demande un accès, mais qu’aucune fonction lisible, documentée ou observable ne semble l’exiger, cette asymétrie doit être traitée comme un signal négatif. Une extension sérieuse devrait pouvoir justifier techniquement sa surface d’accès.
Enfin, il faut regarder ce qui est demandé immédiatement et ce qui pourrait l’être à la demande. Une extension sobre n’est pas nécessairement celle qui demande le moins de permissions dans l’absolu, mais celle qui évite les accès permanents non indispensables.
Questions d’audit à poser avant d’accorder sa confiance
- Quelles APIs l’extension demande-t-elle exactement dans
permissions? - Pourquoi ces APIs sont-elles nécessaires au fonctionnement annoncé ?
- Le périmètre de
host_permissionsest-il ciblé ou quasi global ? - Des permissions optionnelles auraient-elles pu remplacer des permissions permanentes ?
- Le manifeste révèle-t-il une logique de moindre privilège ou une logique de collecte maximale ?
- Les avertissements affichés à l’utilisateur sont-ils cohérents avec la promesse du produit ?
- L’extension demande-t-elle un accès durable là où un accès contextuel aurait suffi ?
- Le discours “privacy” est-il appuyé par une surface d’accès réellement contenue ?
Ces questions ne remplacent pas l’analyse du code ou du comportement réseau, mais elles permettent déjà de distinguer une extension techniquement disciplinée d’une extension dont la confiance repose surtout sur son habillage.
Ce que cette page doit changer dans la lecture du produit
Après lecture du manifeste, une extension VPN ne devrait plus être perçue comme une promesse abstraite de protection, mais comme un composant doté d’un périmètre de pouvoir explicite. Ce changement de lecture est essentiel : on passe d’un jugement marketing à une évaluation de surface d’accès.
La suite logique consiste à relier ce périmètre déclaré à ce que l’extension fait réellement dans le navigateur. C’est précisément le rôle de Proxy, PAC et routage navigateur, puis de Comment auditer une extension VPN avant déploiement.
Conclusion
Dans une extension VPN, les permissions ne sont pas un détail administratif. Elles constituent
le périmètre de confiance explicite accordé par le navigateur. Lire correctement
permissions, host_permissions, les variantes optionnelles et les
avertissements associés, c’est déjà commencer l’audit technique du produit.