Comment auditer une extension VPN avant déploiement

Dossier technique

Une extension VPN ne doit pas être validée sur la base d’une promesse de confidentialité, d’un changement d’IP visible ou d’une bonne réputation de marque. Un audit sérieux commence par le périmètre technique réel : couche d’action, permissions, logique de routage, politique de traitement des requêtes, surface d’exposition restante, comportement sous Manifest V3, et compatibilité entre le produit annoncé et l’architecture effectivement observable.

Auditer une extension VPN ne consiste pas à vérifier si elle “fonctionne”. Cette formulation est trop faible. Une extension peut sembler fonctionner tout en laissant subsister des angles morts, une surface de permissions excessive, une politique de routage opaque ou une incohérence entre l’interface affichée et le contrôle réellement exercé dans le navigateur.

Le bon audit est un audit de périmètre, de discipline technique et de lisibilité. Il cherche à répondre à trois questions simples : sur quelle couche l’extension agit-elle, quels pouvoirs le navigateur lui accorde-t-il réellement, et quelle part du comportement annoncé reste impossible à démontrer proprement avant déploiement.

Le but d’un audit n’est pas de classer, mais d’écarter

Un audit utile n’a pas pour rôle principal de produire un “top” ou une préférence vague. Il sert d’abord à exclure les implémentations insuffisamment maîtrisées. Tant qu’une extension ne passe pas certains seuils de cohérence, il est inutile de la comparer finement à d’autres.

Cette logique impose un ordre de lecture strict :

1. déterminer le périmètre réel du produit ;
2. lire ce que le manifeste autorise effectivement ;
3. comprendre la politique de routage ;
4. identifier le mécanisme d’action sur les requêtes ;
5. mesurer la surface d’exposition restante ;
6. tester la robustesse sous Manifest V3 ;
7. décider si le produit mérite seulement d’entrer dans la phase de validation plus fine.

Étape 1 : qualifier le périmètre réel du produit

La première erreur à éviter est la confusion de couche. Une extension VPN est un composant de navigateur, pas un équivalent implicite d’un client VPN système. Si cette distinction n’est pas posée d’emblée, tout l’audit devient flou.

Il faut donc vérifier :

• si le produit revendique explicitement un périmètre navigateur ou laisse entendre une couverture plus large ;
• si la documentation distingue correctement trafic web du navigateur et trafic global du poste ;
• si l’interface ou le wording entretiennent une confusion entre “IP différente dans un onglet” et “contrôle réseau complet”.

Toute ambiguïté ici est un premier signal négatif. Le produit doit être jugé à la couche où il agit réellement, pas à la couche qu’il suggère.

Cette étape renvoie directement à Extension VPN vs application VPN.

Étape 2 : lire le manifeste avant de juger l’interface

Le manifeste est le premier document technique sérieux du produit. Il révèle la permission proxy quand l’extension agit sur les paramètres proxy du navigateur, les capacités réseau via webRequest ou declarativeNetRequest, les accès de confidentialité via privacy, et le périmètre hôte demandé via host_permissions.

L’audit doit donc vérifier :

• les permissions API réellement demandées ;
• la présence ou non de permissions optionnelles ;
• l’étendue de host_permissions ;
• la cohérence entre les capacités demandées et les fonctions revendiquées.

Une extension qui demande large sans nécessité claire n’est pas “prête pour l’avenir”. Elle est simplement expansive. Une extension techniquement disciplinée doit pouvoir expliquer pourquoi chaque capacité existe et pourquoi elle n’a pas pu être bornée plus finement.

Pour cette partie, la lecture détaillée se trouve dans Permissions et host_permissions.

Étape 3 : vérifier le modèle de permissions comme surface de confiance

Le modèle de permissions ne doit pas être traité comme un détail administratif. Il matérialise la confiance que le navigateur accorde à l’extension. Plus une extension demande d’accès API, de permissions hôte et de capacités de manipulation du trafic, plus l’audit doit être strict.

Une bonne lecture consiste à classer les permissions selon leur rôle :

• permissions structurelles sans impact direct fort sur la visibilité du trafic ;
• permissions réseau et requêtes ;
• permissions de confidentialité ;
• permissions ouvrant une surface de lecture ou d’action large sur les sites visités.

Il faut aussi regarder si l’extension exploite des permissions optionnelles quand cela serait possible. Un produit qui demande tout d’emblée sans hiérarchiser ses besoins inspire moins confiance qu’un produit qui réduit sa surface initiale puis élève les droits uniquement si une fonction réelle l’exige.

Étape 4 : comprendre la politique de routage avant de tester la “connexion”

Une extension VPN ne doit pas être validée sur la base d’un bouton “Connected”. Il faut d’abord comprendre comment elle agit sur le routage du navigateur. Utilise-t-elle chrome.proxy avec fixed_servers ? Un script PAC ? Des exclusions dans bypassList ? Un retour au mode system ? Un fallback silencieux vers du direct ?

Les points à vérifier sont les suivants :

• mode de ProxyConfig réellement utilisé ;
• présence et rôle de singleProxy, fallbackProxy ou de règles par protocole ;
• existence d’un bypassList et portée réelle des exceptions ;
• lisibilité d’un éventuel script PAC ;
• cohérence entre le message produit et la politique de sortie effectivement définie.

Une politique de routage opaque doit être traitée comme un défaut, même si l’interface semble simple. Le navigateur doit sortir selon une logique lisible, pas selon une boîte noire impossible à relire.

Pour cette lecture, voir Proxy, PAC et routage navigateur.

Étape 5 : identifier le mécanisme de traitement des requêtes

Une extension peut agir sur les requêtes via webRequest, via declarativeNetRequest, ou via une combinaison des deux. Le choix technique change profondément la manière dont il faut lire le produit.

• webRequest reste utile pour observer le cycle de vie des requêtes ;
• declarativeNetRequest permet au navigateur d’appliquer des règles déclarées à l’avance ;
• en MV3, le blocage synchrone de type webRequestBlocking n’est plus la norme pour les extensions classiques ;
• les actions déclaratives n’exigent pas toutes le même niveau de host_permissions.

Il faut donc vérifier si l’extension :

• observe plus qu’elle n’agit réellement ;
• délègue proprement la politique au navigateur ;
• cumule des règles difficiles à relire ;
• ou dépend d’un cas particulier de déploiement administré pour tenir ses promesses.

Cette étape renvoie à declarativeNetRequest vs webRequest.

Étape 6 : mesurer la surface d’exposition restante

Un audit qui s’arrête au routage principal est incomplet. Il faut regarder ce qui subsiste autour du proxy du navigateur : WebRTC, politiques IP, résolution anticipée, interfaces utilisables, comportements réseau de confidentialité que l’extension choisit ou non de gouverner via chrome.privacy.

Les questions minimales sont les suivantes :

• l’extension gère-t-elle explicitement webRTCIPHandlingPolicy ;
• documente-t-elle le rôle de WebRTC et des interfaces locales ;
• agit-elle ou non sur les réglages comme networkPredictionEnabled ;
• la promesse de confidentialité ignore-t-elle complètement cette surface restante.

Une extension n’a pas besoin de fermer tous les angles morts pour être techniquement valable. En revanche, elle doit au minimum ne pas faire croire qu’un simple changement d’IP visible suffit à prouver une couverture homogène.

Cette lecture se fait avec Fuites et surface d’exposition.

Étape 7 : tester la robustesse sous Manifest V3

Une extension VPN sérieuse doit être pensée pour fonctionner dans un modèle MV3 fondé sur un service worker événementiel. Cela implique un cycle de vie non persistant, la perte normale des variables globales quand le worker s’arrête, la nécessité de recharger l’état, et l’interdiction de s’appuyer naïvement sur un contexte en mémoire censé vivre en continu.

L’audit doit donc examiner :

• la présence d’un background.service_worker propre ;
• la manière dont l’état est persisté puis rechargé ;
• l’enregistrement synchrone des listeners critiques ;
• l’usage de chrome.storage, d’IndexedDB ou d’un support adapté ;
• la dépendance éventuelle à des timers fragiles au lieu de chrome.alarms ;
• la cohérence du comportement après réveil du service worker.

Une extension qui perd sa cohérence après dormance ne doit pas être déployée, même si elle paraît convaincante dans un test superficiel de quelques secondes.

Pour cette partie, voir Manifest V3 et service workers.

Étape 8 : confronter le produit à sa documentation

Un audit purement technique reste insuffisant si la documentation du produit entretient un faux cadrage. Il faut donc comparer la promesse formulée par l’éditeur avec ce que l’architecture permet effectivement.

Les signaux de rejet les plus nets sont souvent documentaires :

• absence de distinction entre extension navigateur et VPN système ;
• silence sur les permissions demandées ou leur justification ;
• promesse de protection totale alors que le produit agit clairement dans une couche partielle ;
• aucune explication sur WebRTC, les exclusions, les politiques de routage ou la logique MV3 ;
• vocabulaire marketing qui remplace la description technique.

Une extension sobre techniquement mais opaque dans son discours reste un produit plus risqué à déployer qu’une extension un peu plus exigeante mais correctement expliquée.

Décision : rejeter, retenir sous conditions, ou autoriser

La décision finale ne doit pas être binaire trop tôt. Une grille utile peut tenir en trois niveaux :

• Rejet immédiat : permissions disproportionnées, périmètre trompeur, politique de routage illisible, gestion MV3 fragile, promesse techniquement mensongère.
• Retenu sous conditions : architecture globalement cohérente mais zones d’ombre à lever, documentation insuffisante, points de test complémentaires nécessaires.
• Autorisable : périmètre clair, permissions proportionnées, routage lisible, limitations admises, comportement MV3 stable, documentation honnête.

Ce classement est plus utile qu’une note arbitraire sur 10. Il force à justifier la décision en termes de risques concrets.

Signaux de rejet immédiat

• Le produit présente une extension navigateur comme si elle couvrait naturellement tout le poste.
• Le manifeste montre une surface de permissions beaucoup plus large que ce que la fonction annoncée semble exiger.
• La politique de routage repose sur des exceptions ou des fallback non documentés.
• Le traitement des requêtes est opaque ou incohérent avec la promesse affichée.
• La surface WebRTC et confidentialité réseau est ignorée alors que le discours promet une protection homogène.
• Le comportement sous MV3 semble fragile, dépendant d’un état implicite ou d’un contexte persistant fantasmé.
• La documentation remplace l’explication technique par des slogans.

Le dossier minimal à constituer avant déploiement

Avant toute autorisation réelle, il faut conserver un dossier d’évaluation minimal. Sans cela, la décision n’est pas traçable.

• copie du manifeste analysé ;
• liste des permissions API et des host_permissions ;
• description du mode de routage utilisé ;
• identification du mécanisme de traitement des requêtes ;
• résumé de la surface d’exposition restante ;
• observations sur la robustesse MV3 ;
• écarts constatés entre promesse commerciale et réalité technique ;
• verdict motivé avec conditions éventuelles.

Ce dossier n’a pas besoin d’être lourd. Il doit simplement empêcher qu’une extension soit admise parce qu’elle “a l’air sérieuse”.

En environnement géré, le déploiement doit rester gouverné

Dans un contexte administré, l’audit ne s’arrête pas à l’analyse technique de l’extension. Chrome Enterprise permet de contrôler quelles extensions peuvent être installées, et même de forcer l’installation de certaines extensions dans l’organisation. Cela signifie qu’une validation technique doit être suivie d’une décision de gouvernance explicite : autoriser, bloquer, restreindre, ou imposer.

Autrement dit, déployer une extension VPN dans un parc géré sans politique d’installation claire revient à neutraliser une partie de l’audit. Une extension techniquement acceptable doit encore être administrativement maîtrisée.

Principe final

Une extension VPN n’est pas crédible parce qu’elle parle de confidentialité. Elle devient crédible quand son manifeste, sa politique de routage, son modèle de traitement des requêtes, sa gestion de la surface d’exposition et son comportement sous MV3 racontent tous la même histoire. L’audit doit vérifier cette cohérence. S’il ne la trouve pas, la bonne décision n’est pas d’espérer, mais d’écarter.

Conclusion

Auditer une extension VPN avant déploiement revient à transformer un objet marketing en objet technique. Tant que le produit reste lu à travers son interface, son branding ou son changement d’IP apparent, l’évaluation reste faible. Dès qu’on lit le périmètre, les permissions, le routage, les mécanismes réseau, les angles morts et la robustesse MV3, la décision devient enfin défendable.