Connection-Allowlist
Connection-Allowlist liste les destinations autorisées pour une page, et Chrome bloque le reste. Syntaxe, valeurs et prise en charge depuis Chrome 152.
Dernière mise à jour:
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.
Chromium uniquement
Chrome active Connection-Allowlist par défaut à partir de Chrome 152. Firefox et Safari ne l'implémentent pas, donc gardez la directive CSP connect-src pour ces navigateurs. La spec reste un Draft Community Group Report du WICG.
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-endpointComment 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. Le navigateur bloque tout le reste : les fetch, les sous-ressources comme
les polices et les images, les navigations, les iframes, les popups, les WebSockets,
WebTransport, WebRTC et les redirections.
Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpointLa 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.
Un motif porte sur l'URL entière, chemin et query compris. Une entrée sans chemin,
comme "https://cdn.example", autorise tous les chemins de cette origine. Une entrée
avec un chemin, comme "https://cdn.example/assets/*", n'autorise que les URL situées
en dessous. Un joker *. ne correspond qu'aux sous-domaines : https://*.example.com
ne correspond pas à https://example.com.
Les URL à scheme local, comme data: et blob:, n'atteignent jamais le réseau, donc
l'allowlist ne s'applique pas à elles.
Destinations WebSocket
Écrivez les destinations WebSocket avec https: ou http:, jamais wss: ou ws:.
Avant de vérifier un WebSocket, le navigateur convertit wss: en https: et ws: en
http:. Une entrée "wss://chat.example.net" ne correspond donc jamais, et la
connexion est bloquée. Écrivez plutôt l'entrée ainsi :
Connection-Allowlist: (response-origin "https://chat.example.net"); report-to=connection-endpointDans cet exemple, l'entrée https://chat.example.net autorise à la fois
https://chat.example.net et wss://chat.example.net.
Valeurs
| Valeur | Statut | Signification |
|---|---|---|
response-origin | Chromium uniquement | Token qui ajoute automatiquement à l'allowlist l'origine qui sert la réponse. |
"https://..." | Chromium uniquement | Un URL Pattern entre guillemets pour une destination autorisée. |
report-to=<name> | Chromium uniquement | Nomme un endpoint Reporting-Endpoints qui reçoit les rapports de violation. |
redirects=block / redirects=allow | Chromium uniquement | Suivre ou non les redirections. Le défaut est block. |
webrtc=block / webrtc=allow | Chromium uniquement | Autoriser ou non les connexions WebRTC. Le défaut est block. |
Les redirections et WebRTC sont bloqués par défaut, pour couper l'exfiltration via une redirection ouverte ou une connexion pair à pair. Ne les réactivez que lorsque vous en avez besoin.
Redirections
redirects=block bloque toute requête redirigée, quelle que soit sa cible. Une
redirection vers une destination autorisée est bloquée, tout comme une redirection qui
reste sur votre propre origine, par exemple de /account vers /account/. Le
navigateur rapporte l'URL demandée par la page, pas la cible de la redirection.
redirects=allow ne vérifie que la première requête. Le navigateur suit ensuite
chaque redirection, où qu'elle mène. Une redirection ouverte sur une destination
autorisée peut alors envoyer des données n'importe où. Ne l'activez que lorsque vos
pages ont besoin d'une redirection, par exemple pour une étape de connexion ou de
paiement.
Où il s'applique
Le header s'applique au document ou au worker dont la réponse le porte :
- Documents : les connexions propres à la page, et les requêtes qui chargent ses iframes et ses popups.
- Workers : un worker dédié, partagé ou service worker suit le header de sa propre réponse de script, pas celui de la page. Envoyez aussi le header sur les scripts de worker. Un worker créé depuis une URL
blob:oudata:hérite de la politique du contexte qui l'a créé. - Iframes cross-origin : la liste du parent décide si l'iframe se charge. Ensuite, le document encadré suit ses propres headers.
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
dans tous les navigateurs. Connection Allowlists ajoute une couche de sortie propre à
Chromium, 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. Gardez connect-src pour tous les navigateurs, et
ajoutez Connection Allowlists quand vous voulez une politique de sortie unique en
refus par défaut dans les navigateurs basés sur Chromium.
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 besoin.
Contournements et limites connus
Il ne protège les utilisateurs que dans les navigateurs basés sur Chromium à partir de la version 152. 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.
Un script de worker servi sans le header n'est pas soumis à la liste de la page. Une iframe cross-origin autorisée par la liste peut se connecter partout où ses propres headers le permettent.
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-endpointLancez d'abord le header Report-Only pendant au moins une semaine, comme le montre le
guide du générateur Connection-Allowlist,
pour voir chaque connexion que la politique bloquerait avant que quoi que ce soit ne
casse. Gardez aussi la directive CSP
connect-src
en application. C'est le contrôle de sortie des navigateurs qui ne prennent pas en
charge Connection Allowlists.
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. Le
générateur Connection-Allowlist
transforme ces rapports en une liste que vous revoyez puis déployez.
Prise en charge par les navigateurs
Chrome et les autres navigateurs basés sur Chromium prennent en charge le header à partir de la version 152, sur desktop et Android, après un origin trial de la version 148 à la 151. La position de Mozilla sur le standard est positive, mais Firefox ne l'implémente pas. Safari ne l'implémente pas, et WebKit n'a pas publié de position. La spec est un Draft Community Group Report du WICG, pas encore sur la voie de standardisation W3C.
Chrome mène aussi un origin trial distinct, de la version 156 à la 159, pour l'application intégrée (embedded enforcement). Il permet à une page d'exiger une liste sur les iframes qu'elle intègre.
Voir aussi
- rapport connection-allowlist
- Connection Allowlists, un bac à sable de sortie réseau dans le navigateur
- directive connect-src
- Header Reporting-Endpoints
- Construire une Connection-Allowlist depuis vos rapports
Sources
Network Error Logging
NEL demande au navigateur de signaler les échecs de requêtes au niveau réseau, DNS, TLS, connexion et erreurs HTTP, vers un endpoint que vous contrôlez.
Hérités
Les anciens headers de sécurité comme X-Frame-Options et Feature-Policy, ce qui les a remplacés, et faut-il encore les envoyer.