Connection Allowlists : déploiement et limites

BotBrowser permet de répéter des parcours autorisés dans des contextes déclarés et d'enregistrer les résultats visibles ; il n'implémente ni n'active Connection-Allowlist, ne contrôle pas les en-têtes distants et ne garantit pas le blocage dans chaque navigateur. Cet article ne contient aucun résultat de test BotBrowser. La proposition est une politique d'en-tête de réponse visant à limiter les connexions réseau explicites lancées pour un document ou un worker. L'annonce Chrome du 2026-09-23 décrit une mise à disposition pour tests dans Chrome 152, tandis que la fiche ChromeStatus actuelle indique « Missing feature » sans URL d'annonce. Il faut traiter cet écart comme un problème de preuve datée : l'annonce est un état de déploiement rapporté à une date, la fiche est un instantané distinct, et le texte WICG reste une conception en brouillon, non la preuve qu'un navigateur donné applique la politique.

TL;DR

• Connection-Allowlist est une politique proposée dans un en-tête de réponse pour des destinations de connexion explicites ; elle ne remplace pas toutes les fonctions de Content Security Policy.
• Le document WICG est un brouillon de Community Group. Sa syntaxe et ses exemples décrivent une conception, pas une compatibilité inter-navigateurs.
• L'annonce Chrome du 2026-09-23 indique que Chrome 152 introduit la fonction pour tests ; ChromeStatus, fonctionnalité 5175745573945344, affiche actuellement « Missing feature ». Conservez les deux affirmations avec leur date et leur portée, sans les résumer par « pris en charge ».
• La politique appartient au contexte d'un document ou d'un worker. L'application aux contenus intégrés ajoute une exigence du parent et une voie d'acceptation distincte.
• BotBrowser peut répéter des parcours autorisés dans un contexte déclaré en général, mais cet article ne revendique ni implémentation annoncée ni prise en charge mesurée de Connection-Allowlist. Gardez les contrôles actuels et testez les états d'échec de l'application.

Sommaire

• Ce que contrôle la proposition
• Lire les preuves de déploiement
• Associer la politique à son contexte
• Préparer un test sûr
• Classer les échecs et choisir un repli
• Limite de capacité BotBrowser
• Conclusion pratique

Ce que contrôle la proposition

WICG propose qu'un serveur fournisse une liste de destinations autorisées avec la réponse. L'agent utilisateur vérifierait la destination avant d'établir une connexion explicite pour le contexte. Le texte cite Fetch et d'autres voies de connexion de la plateforme, notamment WebRTC, WebTransport, FedCM, Web Payments, DNS prefetch et les navigations. L'objectif est une couverture large des communications explicites lancées pour ce contexte, plutôt qu'un ensemble de directives indépendantes par type de ressource.

Un exemple illustratif de la proposition est :

Connection-Allowlist: (response-origin "https://cdn.example" "https://api.example"); report-to=connection-policy

Cet exemple décrit une conception ; ce n'est pas une consigne à copier en production. response-origin représente l'origine ayant fourni la réponse. Les motifs URL explicites indiquent d'autres destinations. Le paramètre de rapport proposé relie les violations à un endpoint Reporting API. Il faut vérifier la grammaire exacte, les règles de correspondance, les types de connexion et les rapports dans la révision de spécification et l'implémentation étudiées.

La liste n'est pas une politique générale d'intégrité du contenu. Le modèle de menace WICG se concentre sur les canaux de communication et précise que la politique ne résout ni l'injection de contenu ni le cross-site scripting. Si un script injecté peut lire des données sensibles, bloquer certaines connexions sortantes peut réduire un chemin d'exfiltration, mais ne supprime pas l'injection, ne bloque pas tous les canaux auxiliaires et ne corrige pas un en-tête compromis. C'est une couche de défense en profondeur à promesse limitée.

Cette distinction compte pour la comparaison avec Content Security Policy. CSP reste utile pour les restrictions de sources, de scripts et d'autres ressources. La motivation WICG est qu'une règle centrée sur les connexions pourrait couvrir plus globalement les connexions explicites que des catégories de ressources séparées. Cette motivation de conception ne prouve ni que CSP est obsolète ni qu'un nouvel en-tête se compose correctement avec chaque politique. Conservez les contrôles existants jusqu'à ce que le comportement du navigateur cible soit établi pour chaque classe de requête.

La proposition concerne les destinations, pas le sens métier d'une requête. Un appel vers une API autorisée peut toujours contenir des données que l'application ne devrait pas divulguer. Un appel bloqué ne prouve ni que la page est sûre, ni qu'aucun canal auxiliaire n'a exposé de données, ni qu'une opération antérieure n'a pas atteint le service. Autorisation, consentement, validation et audit serveur gardent leurs responsabilités actuelles.

Lire les preuves de déploiement

L'annonce Chrome publiée le 2026-09-23 s'intitule « Connection allowlists: Secure your web application's network access ». Elle indique que Chrome 152 introduit Connection Allowlists et présente le changement comme un moyen de restreindre l'accès réseau d'une page. C'est une preuve utile de déploiement, mais elle ne précise pas à elle seule tous les canaux, plateformes, états activés par défaut, disponibilités d'entreprise ou jalons finaux. Conservez ces réserves dans vos comptes rendus.

La page ChromeStatus de la fonctionnalité 5175745573945344 a un autre rôle. Elle nomme la fonctionnalité « Connection Allowlists », décrit une liste de destinations autorisées transmise par un en-tête HTTP et indique que les destinations correspondantes seraient autorisées et les autres bloquées. Son champ actuel web_feature indique « Missing feature » ; les étapes ne fournissent pas d'URL d'annonce. Cette photographie contredit la formulation de Chrome 152 si les deux sont lues comme décrivant le même état actuel.

Ne résolvez pas l'écart en choisissant silencieusement la page la plus optimiste. Un tableau de statut peut être en retard, employer une autre définition d'étape ou exposer un champ de détection différent d'une annonce produit. À l'inverse, une annonce peut décrire une expérience, des tests développeur ou un déploiement progressif sans prouver le comportement d'un binaire installé. Les pages disponibles ne déterminent pas quelle explication s'applique. La conclusion défendable est plus étroite : l'annonce rapporte une introduction de tests dans Chrome 152 ; l'instantané indique « Missing feature » ; la spécification WICG est un brouillon ; il faut vérifier une version et un canal précis avant de compter sur l'application.

Consignez un petit tuple de preuve au lieu d'un booléen de prise en charge :

Élément de preuve	À consigner	Ne pas déduire
Annonce	URL canonique, date, formulation exacte du jalon Chrome	Disponibilité stable universelle ou toutes plateformes
ChromeStatus	ID, date de consultation, statut affiché et étapes	Qu'un champ décrive intégralement une expérience produit
Spécification	Révision ou date de consultation et statut brouillon	Qu'un texte normatif soit déjà livré dans les navigateurs
Vérification d'exécution	Produit, version, canal, OS, réponse et résultat	Qu'un seul test couvre toutes les API ou versions à venir

L'annonce Chrome datée et la fiche ChromeStatus vivante peuvent évoluer à des moments différents. Conservez une note datée si la décision en dépend. Une fiche ne suffit pas à déclarer la prise en charge ; un champ de statut ne suffit pas non plus à conclure à l'indisponibilité quand une annonce décrit des tests. La proposition de jetons de vérification privée présente une distinction analogue entre le statut d'une proposition Chrome et le comportement disponible. La contradiction impose de borner la décision.

Associer la politique à son contexte

La proposition de base place la politique dans la réponse qui crée un document ou un worker. La question n'est pas seulement « quels domaines figurent dans la liste ? », mais « quel contexte a reçu quelle politique, dans quelle réponse, et quelle opération a lancé la connexion ? » Il ne faut pas supposer que la politique d'une page limite un autre document doté de sa propre réponse et de son propre conteneur de politique. WICG traite l'héritage dans certains contextes locaux, mais les règles exactes doivent être vérifiées dans le brouillon et l'implémentation concernés.

Un iframe ajoute un propriétaire de politique distinct. Le fait que le parent limite ses connexions ne signifie pas qu'un enfant cross-origin utilise la même politique de réponse. L'explicateur WICG d'application aux contenus intégrés propose que l'intégrateur puisse exiger une liste chez l'enfant et que celui-ci accepte avec une politique au moins aussi stricte, un en-tête explicite ou un document local héritant de l'état. Il propose aussi de transmettre l'exigence aux descendants imbriqués. C'est une conception distincte du dépôt, pas un comportement iframe universel déjà livré.

Contexte ou événement	Question de revue	Attente prudente avant vérification
Document principal	La réponse finale contient-elle la politique prévue ?	Garder CSP et les contrôles serveur ; le modèle source ne prouve pas l'en-tête livré.
Worker	Quelle réponse l'a créé, et sa politique est-elle héritée ou déclarée séparément ?	Tester séparément le worker avec des destinations synthétiques.
iframe cross-origin	L'enfant a-t-il accepté l'exigence et quelle réponse a-t-il renvoyée ?	Le traiter comme une frontière distincte jusqu'à observation.
Frame imbriquée	L'exigence se propage-t-elle sans possibilité d'assouplissement ?	Tester chaque niveau ; ne pas extrapoler du seul enfant direct.
Redirection	L'implémentation bloque-t-elle ou autorise-t-elle cette redirection ?	Conserver un résultat distinct ; ne pas ajouter une exception large pour faire passer le test.
Navigation déclenchée par l'utilisateur	S'agit-il d'une connexion explicite de ce contexte ?	Ne pas supposer que l'en-tête de page gouverne le navigateur ou un autre contexte.

Le terme « allowlist » peut suggérer une garantie plus forte que la proposition. Une règle par contexte dépend des types de requêtes couverts, des contextes auxquels elle s'applique, des en-têtes effectivement livrés et de l'implémentation. Si le produit en dépend, nommez des cas séparés pour les workers, service workers, frames imbriquées, redirections, preconnect, WebRTC, WebTransport et navigations.

Connection-Allowlist n'est pas non plus une configuration de proxy. Elle exprime une politique de destination applicative ; un proxy relaie le trafic à une autre couche et possède ses propres responsabilités de routage et d'authentification. La carte des frontières réseau du navigateur d'entreprise attribue ces responsabilités au navigateur, au proxy, au réseau d'entreprise et au service de destination. Pour le protocole, le guide sur la sémantique des proxys HTTP explique les requêtes, CONNECT, DNS et les frontières d'origine. Le guide Permissions Policy porte sur les capacités navigateur déléguées ; une délégation de capacité n'est pas une liste de destinations réseau.

Préparer un test sûr

Avant d'adopter une nouvelle fonction dans un vrai service, définissez une page de test maîtrisée avec des données synthétiques et une courte liste de destinations attendues. Rendez la décision observable sans conserver d'identifiant de compte, de charge utile de production, d'identifiants secrets ou de parcours utilisateur. Utilisez des endpoints de test contrôlés par l'équipe. N'envoyez jamais de données sensibles pour prouver le fonctionnement d'un blocage.

Commencez par deux cas. Le premier envoie une requête vers une destination censée correspondre à la liste ; le second tente une destination absente. Utilisez un récepteur de test local ou maîtrisé et vérifiez s'il a reçu la requête. Un message console et le résultat du récepteur ne répondent pas à la même question. Ne confondez pas un refus attendu avec un problème DNS, TLS, CORS, un délai expiré ou une erreur serveur.

Ajoutez des cas selon les parcours dont dépend le produit : Fetch, ressource image ou script, requête de worker, frame imbriquée, ou établissement WebRTC/WebTransport. La proposition vise plusieurs connexions explicites, mais la suite doit suivre le graphe d'appels réel de l'application et le périmètre documenté du navigateur. Il n'est pas nécessaire de créer un inventaire réseau des utilisateurs ; un petit ensemble synthétique avec des responsables identifiés suffit.

Une fiche de revue peut adopter cette forme stable :

{
  "fixture": "connection-policy-smoke-v1",
  "browser": "produit, version, canal et OS déclarés",
  "context": "top-level-document",
  "policySource": "révision de l'en-tête de réponse de test",
  "case": "listed-endpoint",
  "expected": "requête reçue par le récepteur de test maîtrisé",
  "observed": "consigner le résultat réel et borné",
  "applicationFallback": "garder le contenu principal disponible et proposer une nouvelle tentative",
  "dataClass": "synthetic"
}

Cette forme est un exemple, pas un résultat ni un test BotBrowser. Remplacez les marqueurs uniquement dans un test autorisé réel. Ne placez pas dans un article public ou une preuve durable une URL contenant un secret, un corps de requête, un cookie, un ID de compte ou un identifiant de profil persistant. Version navigateur et révision du fixture sont utiles ; une trace utilisateur complète ne l'est pas.

Rendez le test visible à trois niveaux. Au niveau réponse, vérifiez la réponse finale et l'en-tête exact après redirection. Au niveau navigateur, consignez le parcours de requête prévu et le signalement ou blocage éventuel. Au niveau application, vérifiez que l'interface affiche l'état attendu et que le contenu essentiel reste utilisable. Un niveau ne remplace pas les autres : l'en-tête dans la configuration ne prouve pas sa livraison par le CDN, et un marqueur visuel ne prouve pas qu'une requête réseau a été bloquée.

Bornez les délais et distinguez les échecs de préparation. Si la page ne charge pas, consignez une panne de disponibilité. Si le récepteur est inaccessible, le résultat attendu n'a pas été observé. Si le navigateur ne reconnaît pas la politique, indiquez que la prise en charge n'est pas vérifiée plutôt que de qualifier le résultat d'« autorisé ». Toute exception ne prouve pas un blocage réussi. Chaque erreur doit conserver sa phase et sa cause d'origine.

N'utilisez un mode rapport ou télémétrie que si l'implémentation et la spécification le définissent explicitement et si sa sémantique est vérifiée. N'inventez pas d'en-tête de surveillance et ne déduisez pas que report-to fonctionne parce qu'il apparaît dans un exemple. Sans mode d'observation sûr, commencez par un fixture hors production et un plan réversible. Définissez l'approbateur, l'expiration des entrées, la restauration d'une dépendance et l'examen des exceptions. Un joker annulerait précisément la décision évaluée.

Classer les échecs et choisir un repli

Résultat observé	Premier responsable à vérifier	Prochaine étape sûre
L'en-tête manque sur la réponse finale	Origine, CDN ou configuration de déploiement	Comparer la réponse livrée au fixture ; ne pas inférer la prise en charge du navigateur.
La destination incluse échoue avant le récepteur	DNS, TLS, route, serveur ou motif	Vérifier la phase et la destination normalisée avec des données synthétiques.
La destination exclue atteint le récepteur	Implémentation, périmètre ou couverture	Conserver la preuve et noter version, canal, contexte et API ; ne pas compter sur ce build comme contrôle.
Une destination incluse est bloquée	Syntaxe, motif, redirection ou défaut	Reproduire en changeant une variable ; ne pas élargir la liste avant d'en connaître la cause.
Le blocage rend la page inutilisable	Repli applicatif et propriété de la dépendance	Restaurer la configuration connue ou afficher un état d'indisponibilité compréhensible.
Une frame diffère du parent	Réponse de l'enfant et exigence de l'intégrateur	Consigner les deux réponses et l'acceptation ; ne pas transposer le résultat du parent.

Une panne de service tiers et un refus de politique ne sont pas interchangeables. L'interface doit signaler l'indisponibilité de la ressource, préserver le reste de la page et proposer une nouvelle tentative délibérée si nécessaire. N'affichez pas un succès de sécurité simplement parce qu'une requête a échoué : un délai expiré peut être une panne réseau, pas une décision de liste.

Associez le rollback au changement de configuration. Conservez le dernier en-tête connu et la liste de dépendances afin que le responsable restaure une destination essentielle sans modifier des contrôles sans rapport. Toute exception temporaire doit nommer la destination, la raison, le propriétaire, l'expiration et le test de suivi. Ne transformez pas une difficulté temporaire en joker permanent, ne désactivez pas CSP et ne retirez pas une assertion de refus pour rendre un build vert.

La bonne décision peut être de différer. Si la version navigateur est inconnue, si les sources divergent, si une route critique manque de preuves ou si le repli exposerait un comportement sensible, gardez les contrôles serveur et CSP et classez Connection-Allowlist comme non utilisée. Définissez une condition d'arrêt : si une destination synthétique exclue atteint le récepteur, ce build et ce contexte ne sont pas un contrôle accepté.

Limite de capacité BotBrowser

De manière générale, BotBrowser peut répéter un parcours autorisé dans un contexte déclaré et enregistrer les résultats exposés par l'application. Cela ne signifie pas que le produit configure, analyse, applique ou rapporte Connection-Allowlist. Aucune documentation d'implémentation BotBrowser ni aucun relevé de test de cette fonction n'est cité ici, et BotBrowser n'a pas été exécuté pour cet article. Le modèle de fixture n'est ni une commande produit, ni une option prise en charge, ni un résultat de compatibilité mesuré.

Si une équipe évalue plus tard la fonction dans un parcours BotBrowser autorisé, elle doit d'abord confirmer le binaire exact, la version, la plateforme, le profil, les conditions de lancement, l'en-tête de réponse et le résultat du récepteur. Les cas document, worker et frame doivent être vérifiés séparément. Si le runtime n'applique pas l'en-tête, une réponse qui ressemble à une politique ou une erreur applicative ne crée pas la prise en charge. Limitez le résultat au build et au fixture testés et gardez un repli sûr.

BotBrowser ne peut pas contrôler les en-têtes d'un site, rendre l'expérience Chrome disponible dans un autre navigateur, garantir les mêmes correspondances entre implémentations, certifier la sécurité d'un site, supprimer XSS, empêcher tous les canaux auxiliaires ni prouver qu'un serveur distant n'a reçu aucune donnée par une autre voie. Il ne peut pas non plus réconcilier une fiche de statut et une annonce datée. Ce sont des limites de preuve et d'implémentation, pas des réglages à contourner.

Pour examiner l'ensemble des contrôles, le guide Content Security Policy décrit le rôle distinct de CSP. Considérez les deux mécanismes comme potentiellement complémentaires et vérifiez leur composition réelle dans le runtime cible avant de remplacer l'un par l'autre.

Conclusion pratique

Connection Allowlists est une proposition prometteuse et circonscrite pour contrôler les connexions explicites lancées par un document ou worker, mais les preuves sont liées à une date et à un contexte. L'annonce du 2026-09-23 indique que Chrome 152 introduit des tests ; ChromeStatus affiche actuellement « Missing feature » pour 5175745573945344 ; la spécification WICG est un brouillon. Consignez ces trois faits ensemble, précisez le build et le périmètre, et ne comptez pas sur l'application avant qu'un fixture synthétique confirme les parcours nécessaires.

L'étape prudente consiste à garder les contrôles actuels, créer un test maîtrisé à deux destinations avec un repli lisible et revoir les sources officielles avant de modifier les en-têtes de production. Une vérification contrôlée n'établirait le résultat que pour le navigateur, le contexte, la réponse et le fixture déclarés. Elle ne prouverait ni une prise en charge universelle, ni une prévention complète de l'exfiltration, ni une prise en charge BotBrowser.

Pour compléter la revue des signaux de confiance et des limites réseau, consultez Private Verification Tokens : proposition de Chrome et BotBrowser et Frontières réseau de l'entreprise : responsabilités. Ces pages traitent séparément le statut des propositions et les responsabilités par couche.

Sources

• Chrome : Connection allowlists: Secure your web application's network access (2026-09-23)
• ChromeStatus : Connection Allowlists, fonctionnalité 5175745573945344
• WICG : spécification Connection Allowlists
• WICG : explicateur Connection Allowlists
• BotBrowser : fonctionnalités avancées

Conclusion pratique : gardez les contrôles actuels et vérifiez un build et un contexte déclarés avant de dépendre de la proposition.