# 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 cachée dans le chargement d'une police
est traitée aussi sérieusement qu'une fuite via `fetch`.

<Callout type="warn" title="Experimental, origin trial">
  Connection Allowlists est une proposition précoce du WICG. Chrome l'a proposée en origin trial et compte la livrer, tandis que Firefox et Safari n'ont pas annoncé qu'ils la prendraient en charge. Traitez-la comme une piste à tester en report-only, pas comme une dépendance en production.
</Callout>

## 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
contacter l'extérieur : 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 oblige à jongler avec `connect-src`,
`img-src`, `font-src` et d'autres directives séparées, et même ainsi CSP ne couvre
proprement ni WebRTC ni 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://<Endpoint-ID>.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 à la liste, soit une
destination que vous refusez volontiers, puis faites passer la policy au header
`Connection-Allowlist` en enforcement.

```mermaid
flowchart LR
  A["Connection-Allowlist-Report-Only"] --> B["Collect reports<br/>from real traffic"]
  B --> C["Add the destinations<br/>you actually need"]
  C --> D["Enforce with<br/>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 policy
unique, en refus par défaut, qui couvre tous les types de requêtes, utilise la
syntaxe URL Pattern, et atteint WebRTC et les redirections, hors de portée de
`connect-src`. 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 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, avec 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.

<img alt="Les connexions sortantes remontées, groupées par type et par origine, chacune avec sa disposition enforced ou report-only" src="__img0" width="1359" height="412" />

## É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)
