← Tous les articles

Connection Allowlists, un bac à sable des sorties réseau dans le navigateur

CentralCSP Team ·

Dernière mise à jour:

La plupart des défenses côté client tentent d'empêcher du mauvais code de s'exécuter. Connection Allowlists prend l'angle inverse : on suppose que le code s'exécute, et on s'assure qu'il n'a nulle part où envoyer vos données. Un nouveau header navigateur permet à une page de déclarer l'ensemble exact des destinations qu'elle est autorisée à contacter, et le navigateur bloque toute autre connexion sortante, par n'importe quel canal. Une fuite cachée dans le chargement d'une police est traitée aussi sérieusement qu'une fuite via fetch.

Mise à jour, octobre 2026

Chrome active Connection Allowlists par défaut à partir de Chrome 152, après un origin trial de Chrome 148 à 151. Firefox et Safari ne l'implémentent pas, et la spec reste un brouillon du WICG. Lancez-la d'abord en report-only, et gardez connect-src de CSP pour les autres navigateurs.

Le problème qu'elle résout

Une politique de sécurité du contenu (CSP) empêche la plupart des scripts injectés de s'exécuter. Mais un script qui s'exécute bel et bien, une dépendance compromise, un tag malveillant, du code généré par IA que vous n'avez pas relu, peut toujours contacter l'extérieur : poster des données de formulaire volées vers une origine d'attaquant, ouvrir un WebSocket, ou faire sortir des octets cachés dans une URL d'image. Contrôler cette sortie avec CSP oblige à jongler avec connect-src, img-src, font-src et d'autres directives séparées, et même ainsi CSP ne couvre proprement ni WebRTC ni les redirections.

Connection Allowlists recadre le problème autour de la destination, pas du type de requête. Vous listez où la page peut se connecter, et le navigateur refuse tout le reste au niveau réseau.

Comment ça fonctionne

Vous envoyez un header de réponse Connection-Allowlist listant les destinations que la page peut atteindre. Tout ce qui n'est pas sur la liste est bloqué, y compris fetch, WebSocket, WebRTC, navigation, redirections, et chargements de sous-ressources.

Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint

Chaque entrée est un URL Pattern, donc les sous-domaines et wildcards utilisent cette grammaire. Le token response-origin ajoute automatiquement l'origine qui sert la réponse. Deux choses sont bloquées par défaut et vous ne les réactivez que si vous en avez besoin : les redirections (redirects=allow) et WebRTC (webrtc=allow), deux chemins d'exfiltration courants. Bloquer les redirections les arrête toutes, même celles qui restent sur votre propre origine, alors testez vos parcours de connexion et de paiement.

Listez une destination WebSocket avec https:, pas wss:. Le navigateur vérifie un WebSocket sous son URL https:, donc une entrée wss: ne correspond jamais.

La syntaxe complète du header, les valeurs et le payload du report figurent dans la référence Connection-Allowlist.

Déployez-la d'abord en report-only

Comme pour CSP, il existe deux headers, et vous commencez par celui en report-only pour qu'une liste trop stricte produise un report au lieu de casser la page.

Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint

Le navigateur ne bloque rien et envoie un report connection-allowlist pour chaque connexion qu'il aurait bloquée. Collectez-les depuis le trafic réel, confirmez que chaque destination bloquée est soit à ajouter à la liste, soit une destination que vous refusez volontiers, puis faites passer la policy au header Connection-Allowlist en enforcement.

Comment elle se compare à CSP connect-src

Ce n'est pas un remplacement de CSP. La directive connect-src est stable et fonctionne dans tous les navigateurs. Connection Allowlists ajoute une couche propre à Chromium. C'est une policy unique, en refus par défaut, qui couvre tous les types de requêtes et utilise la syntaxe URL Pattern. Elle couvre aussi WebRTC et les redirections, ce que connect-src ne fait pas. Déployez une CSP solide, puis ajoutez Connection Allowlists en report-only pour voir où la couche de sortie aiderait.

Là où CentralCSP intervient

CentralCSP est bâti sur la Reporting API du navigateur et ingère chaque type de report que le navigateur envoie. Un report connection-allowlist atterrit dans le même pipeline que vos reports CSP et COOP/COEP. Pointez Connection-Allowlist-Report-Only vers votre endpoint CentralCSP et vous pourrez observer les connexions bloquées et potentiellement bloquées sur du trafic réel, regroupées par destination, avec le même workflow report-only d'abord que vous appliquez déjà pour CSP. Le générateur Connection-Allowlist transforme ensuite ces reports en une liste que vous revoyez puis déployez. Pour le versant supply chain du même problème, voyez ce que sont Magecart et le formjacking et l'inventaire de scripts qui suit ce qui s'exécute sur vos pages. Commencez gratuitement pour collecter les reports.

Les connexions sortantes remontées, groupées par type et par origine, chacune avec sa disposition enforced ou report-only

Étapes suivantes

Sources

Articles liés