← 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 via une requête de police est traitée aussi sérieusement qu'une fuite via fetch.

Experimental, origin trial

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

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

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.

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, soit une que vous êtes content de refuser, 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, 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

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 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