Le header Connection-Allowlist, egress en refus par défaut

Connection-Allowlist déclare en refus par défaut les destinations autorisées pour une page ; le navigateur bloque toute autre connexion sortante.

Connection-Allowlist permet à un document ou à un worker de déclarer l'ensemble exact des destinations auxquelles il a le droit de se connecter. Le navigateur devient alors un filtre en refus par défaut : avant toute connexion, il compare la destination à l'allowlist et bloque tout ce qui ne correspond pas. C'est un bac à sable de sortie réseau, pensé pour couper l'exfiltration de données par n'importe quel canal, qu'elle vienne d'un script compromis, d'une bibliothèque embarquée vulnérable ou de code que vous n'avez pas relu.

Expérimental, origin trial

Connection Allowlists est un Draft Community Group Report du WICG (dernière mise à jour en juin 2026), disponible uniquement via un origin trial Chrome en cours. Rien n'est livré par défaut, et aucun autre moteur n'a annoncé sa prise en charge. La syntaxe et la forme des rapports peuvent encore changer.

Pendant l'origin trial, lancez d'abord le header Report-Only, avec le nom d'endpoint déclaré dans Reporting-Endpoints :

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

Comment il fonctionne

Vous envoyez un header de réponse Connection-Allowlist dont la valeur est une liste de motifs d'URL. Une connexion n'est autorisée que si sa destination correspond à l'un d'eux. Tout le reste (fetch, WebSocket, WebRTC, navigation, redirections, polices, images) est bloqué au niveau réseau.

Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

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

La valeur est une inner list structured-field (RFC 9651). Chaque entrée est soit le token response-origin, soit une chaîne URL Pattern entre guillemets pour une URL absolue, donc les jokers et les sous-domaines utilisent la grammaire URL Pattern (https://*.example.com, https://api.example:*) plutôt que la grammaire host-source de CSP.

Valeurs

Valeur	Statut	Signification
`response-origin`	🧪 Expérimental	Token qui ajoute automatiquement à l'allowlist l'origine qui sert la réponse.
`"https://..."`	🧪 Expérimental	Un URL Pattern entre guillemets pour une destination autorisée.
`report-to=<name>`	🧪 Expérimental	Nomme un endpoint `Reporting-Endpoints` qui reçoit les rapports de violation.
`redirects=block` / `redirects=allow`	🧪 Expérimental	Suivre ou non les redirections. Le défaut est `block`.
`webrtc=block` / `webrtc=allow`	🧪 Expérimental	Autoriser ou non les connexions WebRTC. Le défaut est `block`.

Toutes les valeurs sont expérimentales : le header entier n'existe que derrière l'origin trial Chrome.

Les redirections et WebRTC sont bloqués par défaut, posture volontairement conservatrice qui coupe l'exfiltration via une redirection ouverte ou une connexion pair à pair. Ne les réactivez que lorsque vous en avez besoin.

Application et report-only

Il existe deux headers, avec la même séparation que pour CSP et les autres politiques. Lancez d'abord le header report-only pour voir ce qu'une politique bloquerait sur du trafic réel, puis passez en application ; l'exemple d'ouverture montre cette forme.

Connection-Allowlist applique et bloque ; Connection-Allowlist-Report-Only ne bloque rien et se contente d'envoyer un rapport connection-allowlist pour chaque connexion qu'il aurait bloquée.

Le lien avec connect-src de CSP

Cela ne remplace pas votre politique de sécurité du contenu (CSP). La directive CSP connect-src est stable et largement prise en charge, et c'est le contrôle de sortie à déployer aujourd'hui. Connection Allowlists est la couche de sortie expérimentale qui arrive ensuite, avec trois différences : elle est uniforme sur tous les types de requêtes au lieu d'être découpée en directives par type (connect-src, img-src, font-src), elle utilise la syntaxe URL Pattern, et elle couvre des types de connexions que CSP ne peut pas couvrir, dont WebRTC (la directive webrtc de CSP n'existe que dans la spec, sans aucune prise en charge navigateur), les redirections et les navigations. Utilisez connect-src maintenant ; envisagez Connection Allowlists quand vous voudrez une politique de sortie unique en refus par défaut.

Ce contre quoi il protège

L'exfiltration de données, quel que soit le canal. Le modèle de menace traite une fuite via une requête de police ou d'image aussi sérieusement qu'une fuite via fetch. Puisque toute destination que vous n'avez pas listée est refusée, un skimmer ou une dépendance compromise n'a nulle part où envoyer les données volées, même s'il s'exécute.

Configurations non sûres à éviter

Un motif large comme https://* autorise toute destination HTTPS et anéantit l'allowlist, la même erreur que connect-src * en CSP. Listez des origines précises, et n'activez redirects=allow ou webrtc=allow que lorsqu'une fonctionnalité en a réellement besoin.

Contournements et limites connus

Il est expérimental et limité à Chromium : il ne protège donc les utilisateurs que sur les navigateurs qui l'implémentent, origin trial activé. Il gouverne la destination des connexions, pas ce qu'un script fait dans la page, donc il complète CSP et le traitement des entrées au lieu de les remplacer.

Risques

Une allowlist trop stricte casse des connexions tierces légitimes, c'est pourquoi le header report-only existe. Déployez en report-only, observez ce qu'il bloquerait sur du trafic réel, et resserrez avant de passer en application.

Recommandation

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

Si vous voulez l'évaluer, rejoignez l'origin trial Chrome et lancez d'abord le header Report-Only, pour voir chaque connexion que la politique bloquerait avant que quoi que ce soit ne casse. Gardez la directive CSP connect-src comme contrôle de sortie appliqué entre-temps ; c'est le mécanisme stable et multi-navigateurs tant que Connection Allowlists n'est activé par défaut dans aucun navigateur.

Reporting

Un paramètre report-to=<name> pointe vers un endpoint déclaré dans un header Reporting-Endpoints, et le navigateur émet le rapport connection-allowlist pour chaque connexion bloquée ou qui aurait été bloquée. CentralCSP ingère ce rapport aux côtés de vos rapports CSP et autres rapports navigateur, ce qui vous permet de lancer Connection-Allowlist-Report-Only et d'observer les connexions bloquées sur du trafic réel avant de passer en application.

Prise en charge par les navigateurs

Origin trial Chrome en cours uniquement ; rien n'est livré par défaut, et aucun autre moteur n'a annoncé sa prise en charge. La spec est un Draft Community Group Report du WICG (dernière mise à jour en juin 2026), pas encore sur la voie de standardisation W3C.

Connection-Allowlist