Générateur Connection-Allowlist, une liste depuis vos reports

Générez un header Connection-Allowlist depuis les reports des navigateurs. Partez de votre origine, autorisez les destinations connues, puis déployez.

Le générateur Connection-Allowlist écrit un header Connection-Allowlist à partir de vos propres reports. Vous choisissez les reports à analyser, partez de votre propre origine ou d'une liste que vous collez, décidez quelles destinations reportées autoriser, puis copiez les headers.

Le générateur se trouve sous chaque site, dans la barre latérale, sous Générateurs > Connection-Allowlist. Le même menu Générateurs contient les générateurs Content-Security-Policy et Permissions-Policy. Il fonctionne sur tous les plans, et tous les rôles d'un site peuvent l'utiliser.

Revoyez chaque destination et déployez d'abord en report-only

N'importe quel script de vos pages peut envoyer des données vers une destination que la liste autorise, alors n'autorisez que les destinations que vous reconnaissez. Les réglages par défaut du générateur autorisent chaque destination reportée qui n'est pas du bruit, et une destination reportée ne prouve pas que vos pages s'y connectent. Une liste issue de l'API ou de l'outil MCP applique les mêmes réglages par défaut, sans revue, alors vérifiez-la de la même façon.

Déployez toujours une nouvelle liste d'abord avec le header Connection-Allowlist-Report-Only. Passez à Connection-Allowlist seulement quand au moins une semaine de reports montre que rien de ce dont vos pages ont besoin ne serait bloqué.

Ce que produit le générateur Connection-Allowlist

Le générateur aboutit à deux headers de réponse, prêts à coller dans la configuration de votre serveur ou de votre réseau de diffusion de contenu (CDN). Un header Reporting-Endpoints envoie les reports vers l'endpoint CentralCSP de votre site. Un header Connection-Allowlist-Report-Only porte la liste, ou Connection-Allowlist une fois que vous passez en mode bloquant.

La liste contient response-origin, l'origine depuis laquelle chaque page est servie, et une entrée par destination que vous autorisez. Un site qui compte au moins trois sous-domaines reportés peut partager un seul motif https://*. au lieu d'une entrée pour chacun. La valeur se termine toujours par report-to=centralcsp, pour que le navigateur envoie ses reports à CentralCSP :

Connection-Allowlist-Report-Only: (response-origin "https://*.example.com" "https://api.example.net"); report-to=centralcsp

Le générateur n'enregistre ni ne déploie rien. Il vous fournit les headers, et vous les ajoutez à votre site. Chaque export, les headers en TXT ou le tableau de revue en CSV, est consigné dans le journal d'audit.

Fonctionnement

Le générateur fonctionne en quatre étapes. Chaque étape reprend la réponse de la précédente.

Période : choisissez les jours de reports à analyser, jusqu'aux 30 derniers.
Politique de départ : partez de Votre origine uniquement, soit (response-origin), ou collez la liste que vous envoyez aujourd'hui.
Revoir les destinations : choisissez si le navigateur peut suivre les redirections, puis autorisez ou rejetez chaque destination reportée. Chaque destination arrive déjà tranchée, et le bruit arrive rejeté.
Déployer : choisissez le mode report-only ou bloquant, puis copiez les headers.

Le générateur Connection-Allowlist à l’étape Période, avec 7 jours sélectionnés sur le graphique des reports et les compteurs Rapports, Destinations et Semblent être du bruit

D'où viennent les données

Le générateur lit les reports Connection-Allowlist que votre site collecte déjà. Chaque report cite une connexion que le navigateur a bloquée, ou aurait bloquée en mode report-only. Le générateur ramène chaque URL bloquée à son origine, la destination que vous pouvez autoriser, et compte combien de fois les navigateurs l'ont reportée.

Les connexions WebRTC n'ont pas de destination, elles forment donc une ligne à part. Autoriser cette ligne ajoute webrtc=allow à la liste. Les destinations qui appartiennent à une extension de navigateur sont mises de côté, car une extension ne fait pas partie du trafic de votre site.

Pour savoir comment le générateur regroupe les destinations, repère le bruit et choisit ses réglages par défaut, consultez Règles de décision du générateur.

Pourquoi il ne part jamais d'une liste reportée

Le générateur CSP peut partir de la politique que sert votre site, car chaque report CSP transporte cette politique. Le générateur Connection-Allowlist ne part jamais d'une liste lue dans les reports. Toute personne qui connaît votre endpoint de reporting peut lui 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. Le générateur part de votre propre origine, ou de la liste que vous collez vous-même.

La même prudence s'applique à chaque destination reportée. Revoyez ce que vous autorisez à l'étape Revoir les destinations.

Prise en charge par les navigateurs

Seuls les navigateurs basés sur Chromium prennent en charge Connection-Allowlist. Les autres navigateurs ignorent le header, gardez donc la directive connect-src de votre politique de sécurité du contenu (CSP) comme contrôle des sorties pour eux. L'étape de déploiement rappelle cette remarque. Pour l'état actuel de la prise en charge, consultez Prise en charge de Connection-Allowlist par les navigateurs.

Utilisation depuis l'API et le serveur MCP

L'API REST construit la même liste sans l'assistant. L'endpoint Build a recommended Connection-Allowlist accepte une période et une liste de départ, toutes deux facultatives. Sans liste de départ, il part de (response-origin). Il renvoie la liste sous forme de valeur de header dans policy, et la valeur Reporting-Endpoints à envoyer avec elle dans reportingEndpoints. Il applique les mêmes réglages par défaut que le dashboard. Consultez la référence de l'API.

Le serveur Model Context Protocol (MCP) expose cet endpoint sous la forme de l'outil build_recommended_connection_allowlist.