# Connection Allowlists, un bac à sable des sorties réseau dans le navigateur (/fr/blog/connection-allowlists-network-egress) 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 via une requête de police est traitée aussi sérieusement qu'une fuite via `fetch`. Connection Allowlists est une proposition précoce du WICG. Chrome l'a proposée en origin trial et a l'intention de la livrer, tandis que Firefox et Safari n'ont pas signalé de soutien. Considérez-la comme quelque chose à piloter en report-only, pas comme une dépendance en production. ## Le problème qu'elle résout [#le-problème-quelle-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 appeler chez lui : 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 signifie jongler avec `connect-src`, `img-src`, `font-src`, et plus encore, chacune une directive distincte, et même ainsi CSP ne peut pas couvrir proprement WebRTC ou 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 [#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. ```http Reporting-Endpoints: connection-endpoint="https://.report.centralcsp.com" ``` ```http Connection-Allowlist: (response-origin "https://*.example.com" "https://cdn.example"); report-to=connection-endpoint ``` Chaque entrée est un [URL Pattern](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API), 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. La syntaxe complète du header, les valeurs et le payload du report figurent dans la [référence Connection-Allowlist](/fr/docs/web-security/policies/connection-allowlist). ## Déployez-la d'abord en report-only [#déployez-la-dabord-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. ```http Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint ``` Le navigateur ne bloque rien et envoie un [report `connection-allowlist`](/fr/docs/web-security/reporting-api/reports/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, soit une que vous êtes content de refuser, puis faites passer la policy au header `Connection-Allowlist` en enforcement. ```mermaid flowchart LR A["Connection-Allowlist-Report-Only"] --> B["Collect reports
from real traffic"] B --> C["Add the destinations
you actually need"] C --> D["Enforce with
Connection-Allowlist"] ``` ## Comment elle se compare à CSP connect-src [#comment-elle-se-compare-à-csp-connect-src] Ce n'est pas un remplacement de CSP. La directive [`connect-src`](/fr/docs/web-security/policies/content-security-policy/directives/connect-src) est stable, largement prise en charge, et le contrôle de sortie à utiliser aujourd'hui. Connection Allowlists est la couche suivante expérimentale : une seule policy par refus par défaut qui couvre tous les types de requêtes, utilise la syntaxe URL Pattern, et couvre WebRTC et les redirections que `connect-src` ne couvre pas. Déployez une CSP solide maintenant, et pilotez Connection Allowlists en report-only pour voir où la couche de sortie aiderait. ## Là où CentralCSP intervient [#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, NEL 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, le même workflow report-only-d'abord que vous appliquez déjà pour CSP. Pour le versant supply chain du même problème, voyez [ce que sont Magecart et le formjacking](/fr/blog/magecart-formjacking-detection) et l'[inventaire de scripts](/fr/docs/platform/features/script-inventory) qui suit ce qui s'exécute sur vos pages. [Commencez gratuitement](/register) 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 [#étapes-suivantes] * Lisez la [référence du header Connection-Allowlist](/fr/docs/web-security/policies/connection-allowlist). * Voyez les [champs du report connection-allowlist](/fr/docs/web-security/reporting-api/reports/connection-allowlist). * Verrouillez les sorties dès aujourd'hui avec [connect-src](/fr/docs/web-security/policies/content-security-policy/directives/connect-src). ## Sources [#sources] * [WICG, Connection Allowlists](https://wicg.github.io/connection-allowlists/) * [Chrome for Developers, Connection Allowlists origin trial](https://developer.chrome.com/blog/connection-allowlists-origin-trial) * [MDN, URL Pattern API](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API) ## Articles liés [#articles-liés] * [Ce qu'est Magecart, et comment détecter un skimmer de formjacking](/fr/blog/magecart-formjacking-detection) * [Permissions-Policy expliquée](/fr/blog/permissions-policy-explained) * [Qu'est-ce que NEL, le network error logging du navigateur](/fr/blog/what-is-nel-network-error-logging)