# Connection-Allowlist (/fr/docs/web-security/policies/connection-allowlist)



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.

<Callout type="warn" title="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.
</Callout>

Pendant l'origin trial, lancez d'abord le header Report-Only, avec le nom d'endpoint
déclaré dans [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) :

```http
Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpoint
```

## Comment il fonctionne [#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.

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

La valeur est une inner list structured-field
([RFC 9651](https://www.rfc-editor.org/rfc/rfc9651)). Chaque entrée est soit le token
`response-origin`, soit une chaîne [URL Pattern](https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API)
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](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source).

## Valeurs [#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`](/fr/docs/web-security/reporting-api/headers/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 [#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`](/fr/docs/web-security/reporting-api/reports/connection-allowlist)
pour chaque connexion qu'il aurait bloquée.

## Le lien avec connect-src de CSP [#le-lien-avec-connect-src-de-csp]

Cela ne remplace pas votre politique de sécurité du contenu (CSP). La directive CSP
[`connect-src`](/fr/docs/web-security/policies/content-security-policy/directives/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](/fr/docs/web-security/policies/content-security-policy/directives/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 [#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 [#configurations-non-sûres-à-éviter]

<Callout type="warn">
  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.
</Callout>

## Contournements et limites connus [#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 [#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 [#recommandation]

```http
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`](/fr/docs/web-security/policies/content-security-policy/directives/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 [#reporting]

Un paramètre `report-to=<name>` pointe vers un endpoint déclaré dans un header
[`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints), et le
navigateur émet le
[rapport `connection-allowlist`](/fr/docs/web-security/reporting-api/reports/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 [#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.

## Voir aussi [#voir-aussi]

* [rapport connection-allowlist](/fr/docs/web-security/reporting-api/reports/connection-allowlist)
* [Connection Allowlists, un bac à sable de sortie réseau dans le navigateur](/fr/blog/connection-allowlists-network-egress)
* [directive connect-src](/fr/docs/web-security/policies/content-security-policy/directives/connect-src)
* [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)

## Sources [#sources]

* [WICG, Connection Allowlists](https://wicg.github.io/connection-allowlists/)
* [WICG/connection-allowlists explainer](https://github.com/WICG/connection-allowlists)
* [Chrome for Developers, Connection Allowlists origin trial](https://developer.chrome.com/blog/connection-allowlists-origin-trial)