# Vue d'ensemble (/fr/docs/platform/features/builders/connection-allowlist) Le générateur Connection-Allowlist écrit un header [Connection-Allowlist](/fr/docs/web-security/policies/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. 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 [#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`](/fr/docs/web-security/reporting-api/headers/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 : ```http 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](/fr/docs/platform/security/audit-log#exports). ## Fonctionnement [#fonctionnement] Le générateur fonctionne en quatre étapes. Chaque étape reprend la réponse de la précédente. 1. **Période** : choisissez les jours de reports à analyser, jusqu'aux 30 derniers. 2. **Politique de départ** : partez de **Votre origine uniquement**, soit `(response-origin)`, ou collez la liste que vous envoyez aujourd'hui. 3. **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é. 4. **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 [#doù-viennent-les-données] Le générateur lit les [reports Connection-Allowlist](/fr/docs/web-security/reporting-api/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](/fr/docs/platform/features/builders/connection-allowlist/how-it-decides). ### Pourquoi il ne part jamais d'une liste reportée [#pourquoi-il-ne-part-jamais-dune-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](/fr/docs/platform/features/builders/connection-allowlist/review-destinations). ## Prise en charge par les navigateurs [#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`](/fr/docs/web-security/policies/content-security-policy/directives/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](/fr/docs/web-security/policies/connection-allowlist#prise-en-charge-par-les-navigateurs). ## Utilisation depuis l'API et le serveur MCP [#utilisation-depuis-lapi-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](/fr/docs/api-mcp/api). Le [serveur Model Context Protocol (MCP)](/fr/docs/api-mcp/mcp) expose cet endpoint sous la forme de l'outil `build_recommended_connection_allowlist`. ## Étapes suivantes [#étapes-suivantes] * [Démarrer](/fr/docs/platform/features/builders/connection-allowlist/get-started) * [Revoir les destinations](/fr/docs/platform/features/builders/connection-allowlist/review-destinations) * [Règles de décision du générateur](/fr/docs/platform/features/builders/connection-allowlist/how-it-decides) * [Vue d'ensemble des générateurs](/fr/docs/platform/features/builders) * [Reports Connection-Allowlist](/fr/docs/platform/monitoring/connection-allowlist) * [Connection Allowlists, un bac à sable de sortie réseau dans le navigateur](/fr/blog/connection-allowlists-network-egress)