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

Connection-Allowlist déclare une allowlist en refus par défaut des destinations autorisées pour une page, et 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 gardien en refus par défaut : avant toute connexion, il vérifie la destination contre l'allowlist et bloque tout ce qui ne correspond pas. C'est un bac à sable de sortie réseau, conçu pour stopper l'exfiltration de données par n'importe quel canal, un script compromis, une bibliothèque embarquée vulnérable, ou du 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 signalé de support. 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ées par défaut, une posture volontairement conservatrice pour stopper 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 y a deux headers, la même séparation que 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 appliquez ; 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 support 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. En refusant chaque destination que vous n'avez pas listé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

Expérimental et limité à Chromium, donc il ne protège les utilisateurs que sur les navigateurs qui l'implémentent avec l'origin trial activé. Il gouverne la destination des connexions, pas ce qu'un script fait dans la page, donc il complète plutôt qu'il ne remplace CSP et le traitement des entrées.

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 d'appliquer.

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 livré par défaut nulle part.

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, pour lancer Connection-Allowlist-Report-Only et observer les connexions bloquées sur du trafic réel avant d'appliquer.

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 signalé de support. 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