# Règles de décision du générateur (/fr/docs/platform/features/builders/connection-allowlist/how-it-decides)



Le générateur Connection-Allowlist suggère chaque entrée à partir de règles que vous pouvez vérifier. Les connaître vous indique quand faire confiance à un réglage par défaut et quand passer outre.

## Du report à la destination [#du-report-à-la-destination]

Chaque [report Connection-Allowlist](/fr/docs/web-security/reporting-api/reports/connection-allowlist) cite une connexion que le navigateur a bloquée, ou aurait bloquée en mode report-only. Le générateur en tire une destination que vous pouvez autoriser :

| Ce que le navigateur a reporté                                                            | Destination dans la revue                                                         |
| ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Une URL sur un autre site                                                                 | L'origine de l'URL (schéma, hôte et port), par exemple `https://api.example.net`  |
| Une URL sur l'origine depuis laquelle votre page a été servie                             | La même origine, signalée **Déjà autorisé** parce que `response-origin` la couvre |
| Une URL `ws://` ou `wss://`                                                               | Son origine, dans la section **WebSockets**                                       |
| Une connexion WebRTC                                                                      | Une seule ligne **Connexions WebRTC**                                             |
| Une URL d'extension de navigateur                                                         | Rien, la destination est mise de côté                                             |
| Tout ce qui n'est pas une simple origine `http`, `https`, `ws` ou `wss` avec un vrai hôte | Rien, le report est écarté                                                        |

Le générateur écrit des origines nues, sans chemin. Une entrée sans chemin correspond à tous les chemins de cette origine, donc une entrée par destination garde la liste courte, et elle reste valable quand un fournisseur déplace un endpoint. La section **URL bloquées** du panneau de détails affiche tout de même les URL complètes, pour que vous voyiez quel endpoint vos pages appellent.

Les reports peuvent être falsifiés, le générateur vérifie donc chaque destination avant qu'elle ne puisse atteindre le header. Une valeur qui contient un guillemet, un hôte `*` seul ou un schéma hors des quatre ci-dessus ne devient jamais une entrée.

## WebRTC et WebSockets [#webrtc-et-websockets]

Une connexion WebRTC n'a pas d'URL de destination, la liste ne peut donc pas en nommer une. Le générateur regroupe chaque connexion WebRTC reportée en une seule ligne. L'autoriser écrit `webrtc=allow`, qui laisse passer toutes les connexions WebRTC, depuis n'importe quel script de vos pages. Laissez-la rejetée sauf si vos pages passent des appels vidéo ou vocaux, ou établissent d'autres connexions pair à pair. La [directive `webrtc`](/fr/docs/web-security/policies/content-security-policy/directives/webrtc) de CSP, qui couvrirait ce canal, n'est encore prise en charge par aucun navigateur.

Les destinations WebSocket sont des origines ordinaires, comme `wss://chat.example.net`. Elles ont leur propre section pour être faciles à revoir, et chacune s'autorise ou se rejette comme n'importe quelle autre destination. Un sous-domaine WebSocket peut tout de même rejoindre une section de site quand son site remplit les conditions d'un motif.

## Motifs de site [#motifs-de-site]

Un site correspond aux deux derniers libellés d'un hôte, par exemple `example.com` pour `api.example.com`. Sous un code pays doté d'un second niveau courant, comme `co.uk`, le site garde trois libellés, par exemple `example.co.uk`. Le schéma fait partie du site, donc des sous-domaines `https://` et `wss://` d'un même domaine ne partagent jamais un motif. Les adresses IP ne forment jamais un site.

Le générateur propose un motif pour un site dès que les navigateurs ont reporté au moins trois de ses sous-domaines sur le port par défaut :

* Le motif est le site précédé d'un joker `*.`, par exemple `https://*.example.com`, signalé **Recommandé**.
* Il arrive ajouté quand au moins trois de ces sous-domaines sont autorisés, bruit exclu.
* Tant qu'il est ajouté, il autorise chaque sous-domaine qu'il couvre, et ces lignes sont verrouillées avec le libellé **Autorisée par le motif du site**.
* Il ne couvre jamais le site lui-même (`https://example.com`) ni un sous-domaine sur un autre port (`https://api.example.com:8443`). Ceux-ci gardent leur propre entrée.

Un motif autorise aussi des sous-domaines du site que personne n'a reportés. C'est ce qui le garde court, et c'est aussi pourquoi vous devez le rejeter sur un domaine où d'autres personnes peuvent créer des sous-domaines.

## Bruit [#bruit]

Le bruit est une destination reportée dont vos pages n'ont très probablement pas besoin. Le générateur signale une destination comme bruit quand les navigateurs l'ont reportée moins de 10 fois sur la période. Le bruit arrive rejeté, sauf si votre liste de départ l'autorise déjà.

La section **Pourquoi cela ressemble à du bruit** du panneau de détails en donne la raison, avec le nombre de reports correspondant. Elle peut aussi indiquer qu'un seul navigateur a reporté la destination alors que votre site en voit plusieurs. Cette ligne ne fait jamais à elle seule d'une destination du bruit : seuls les navigateurs basés sur Chromium envoient des reports Connection-Allowlist, la plupart des sites ne voient donc qu'un seul navigateur.

Le bruit n'est qu'un réglage par défaut. Une page que peu de gens ouvrent, comme une campagne annuelle, peut produire peu de reports et pourtant être réelle. Vérifiez le filtre **Bruit** avant de déployer.

## Destinations d'extensions de navigateur [#destinations-dextensions-de-navigateur]

Un report qui cite une URL d'extension de navigateur ne devient jamais une destination. Une extension s'exécute sur la machine du visiteur, et une entrée de liste pour elle n'aurait aucun sens. Le générateur met ces destinations de côté, et une remarque sous le tableau de revue en donne le nombre. Pour les écarter avant leur stockage, consultez [Ignorer les reports des extensions de navigateur](/fr/docs/platform/websites/reporting-settings#ignorer-les-reports-des-extensions-de-navigateur).

## Options de départ [#options-de-départ]

Le générateur propose deux points de départ :

| Option                       | Liste de départ                                              | Quand l'utiliser                                                                                     |
| ---------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| **Votre origine uniquement** | `(response-origin)`, avec les redirections et WebRTC bloqués | Votre site n'envoie pas encore de Connection-Allowlist, ou vous voulez reconstruire la liste de zéro |
| **Votre propre politique**   | La valeur que vous collez, jusqu'à 16 384 caractères         | Vous envoyez déjà une liste et voulez conserver ses entrées                                          |

`response-origin` autorise l'origine depuis laquelle chaque page est servie, quel que soit celui de vos hôtes dont il s'agit. Vos pages peuvent toujours rappeler leur propre serveur, donc rien de ce que votre site sert lui-même ne casse.

Quand vous collez une liste, le générateur conserve chaque entrée qu'il sait lire, ainsi que ses réglages `redirects` et `webrtc`. Il retire ce qu'il ne peut pas utiliser : les entrées en double, les entrées hors de la [grammaire des motifs d'URL](/fr/docs/web-security/policies/connection-allowlist#comment-il-fonctionne), et un joker seul comme `https://*`, qui autoriserait toutes les destinations. Son paramètre `report-to` est remplacé par `report-to=centralcsp`. Une entrée avec un chemin est conservée telle quelle, mais le générateur ne la considère comme autorisant aucune destination, donc les destinations qu'elle couvre restent listées pour que vous en décidiez.

Le générateur ne part jamais d'une liste lue dans les reports. Toute personne qui connaît votre endpoint de reporting peut envoyer un report, une liste trouvée dans les reports pourrait donc être falsifiée, et en partir autoriserait des destinations choisies par un attaquant.

## Ce que le générateur n'écrit jamais [#ce-que-le-générateur-nécrit-jamais]

La liste de l'étape de déploiement exclut :

* `redirects=block` et `webrtc=block`. Ce sont les comportements par défaut du navigateur, le générateur n'écrit donc que `redirects=allow` ou `webrtc=allow`.
* Un chemin sur une destination qu'il a ajoutée. Chaque destination ajoutée est une origine nue ou un motif de site.
* Une entrée hors de la grammaire des motifs d'URL, ou un hôte joker suivi de rien.
* Une destination d'extension de navigateur.
* Une seconde copie d'une entrée.

La valeur se termine toujours par `report-to=centralcsp`, le groupe que déclare le header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints). Avec les redirections et WebRTC autorisés, une liste ressemble à cet exemple :

```http
Connection-Allowlist-Report-Only: (response-origin "https://*.example.com" "wss://chat.example.net"); redirects=allow; webrtc=allow; report-to=centralcsp
```

## Périodes et limites [#périodes-et-limites]

Le générateur lit jusqu'aux 30 derniers jours de reports. Un site qui envoie un très gros volume de reports est limité à 7 jours à la fois.

Sur un tel site, l'étape **Période** affiche **Ce site envoie beaucoup de rapports : le générateur ne lit donc que ses 7 derniers jours**, et les options **14 jours** et **30 jours** sont masquées. Si une période contient plus de reports que le générateur ne peut en lire à temps, la page affiche **Cette période contient trop de rapports pour être analysée à temps. Choisissez une période plus courte.** Choisissez moins de jours et continuez.

L'API applique les mêmes limites. L'endpoint **Build a recommended Connection-Allowlist** utilise par défaut les 7 derniers jours, couvre jusqu'à 30 jours, et chaque utilisateur peut l'appeler 10 fois par minute. Il applique les réglages par défaut du générateur sans revue : chaque destination qui n'est pas du bruit est ajoutée, et au moins trois sous-domaines autorisés d'un même site deviennent un motif. Consultez la [référence de l'API](/fr/docs/api-mcp/api).

## Étapes suivantes [#étapes-suivantes]

* [Revoir les destinations](/fr/docs/platform/features/builders/connection-allowlist/review-destinations)
* [Démarrer](/fr/docs/platform/features/builders/connection-allowlist/get-started)
* [Reports Connection-Allowlist](/fr/docs/platform/monitoring/connection-allowlist)
* [Référence Connection-Allowlist](/fr/docs/web-security/policies/connection-allowlist)
