Comment le générateur Connection-Allowlist choisit chaque destination

Comment le générateur Connection-Allowlist transforme les reports en origines, regroupe les sous-domaines, repère le bruit et choisit ses défauts.

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

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

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

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

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

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.

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

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. Avec les redirections et WebRTC autorisés, une liste ressemble à cet exemple :

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

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.

Règles de décision du générateur