CentralCSP
Reports

Connection allowlist

Connexions tentées hors allowlist. Construisez la liste depuis le trafic observé, puis resserrez-la. Une liste permissive est un relevé, pas un contrôle.

Dernière mise à jour:

Cette page liste les tentatives de connexion qui sont sorties de votre allowlist. Là où la CSP raisonne en types de ressource et en directives, ce mécanisme regarde la connexion elle-même, ce qui attrape des sorties qu'une revue de connect-src peut manquer.

Les connexions bloquées sont regroupées par type de connexion et par origine de destination :

Les violations de la liste d'autorisation de connexions, regroupées par type de connexion et origine de destination

Colonnes

Le tableau des reports comporte ces colonnes :

ColonneSignification
Type de connexionLe schéma de l'URL bloquée, par exemple https, ou webrtc pour une connexion WebRTC
Origine de la connexionL'origine de l'URL bloquée, ou webrtc
Origine du documentL'origine de la page qui l'a tentée
NavigateursLes navigateurs qui l'ont signalée
DispositionAppliqué signifie bloqué, Report-only signifie que cela l'aurait été
ReportsLes reports regroupés dans cette ligne
Dernière occurrenceL'occurrence la plus récente

La barre d'outils affine le tableau avec un champ de recherche, qui cherche dans les origines de la connexion et du document, et trois filtres :

  • Tous les types de connexion n'affiche que les connexions HTTPS, HTTP ou WebRTC. Une connexion WebSocket ou WebTransport compte comme HTTPS ou HTTP, le schéma sous lequel le navigateur la reporte.
  • Tous les navigateurs affiche les reports d'un seul navigateur.
  • Toutes les dispositions affiche les reports appliqués ou report-only.

Sélectionner une ligne ouvre son détail, avec chaque URL bloquée complète et la page qui l'a tentée. Les navigateurs n'envoient l'allowlist en vigueur qu'avec les reports WebRTC, le champ Liste d’autorisation reste donc vide pour toutes les autres connexions.

Lire les lignes

Ces lignes méritent un second regard :

  • Un WebSocket apparaît en https. Le navigateur signale une connexion wss: sous son URL https:. Pour l'autoriser, listez l'origine https:, jamais une origine wss:. Voir Destinations WebSocket.
  • Votre propre origine apparaît comme destination. Votre liste autorise votre propre origine via response-origin. Un report qui la nomme signifie en général que le navigateur a bloqué une redirection. Quand les redirections sont bloquées, le navigateur signale l'URL demandée par la page, pas celle vers laquelle la redirection menait.
  • Les compteurs grimpent sur les navigations. Chrome envoie deux reports identiques pour chaque navigation, iframe, popup et preconnect bloqués. Lisez Reports comme un signal relatif, pas comme le nombre exact de tentatives.

Construire la liste à partir du trafic

Démarrez en report-only et laissez les reports définir la liste plutôt que de la deviner. Laissez tourner sur un cycle d'activité normal, au moins une semaine, pour que les connexions périodiques apparaissent. Les flux de fin de mois et les autres tâches rares sont ceux qu'une fenêtre courte rate, donc allongez la période si votre site en a.

Puis resserrez. Une allowlist qui autorise tout ce qui est observé aujourd'hui est un relevé, pas un contrôle. La valeur est dans les entrées que vous décidez de ne pas inclure.

Le générateur Connection-Allowlist, sous Générateurs > Connection-Allowlist, transforme ces reports en liste de départ, avec une entrée par origine de destination et un seul motif *. pour un site qui compte trois sous-domaines reportés ou plus.

Ce qu'il faut chercher

Votre API first-party et les endpoints de prestataires connus constituent l'essentiel de toute liste saine. La partie intéressante est la queue de liste : une origine que personne ne reconnaît, une destination apparue après la mise à jour d'un tiers, ou du trafic issu d'une page qui ne devrait parler à rien d'externe.

Les pages de paiement en premier. Une connexion depuis le tunnel de paiement vers une origine hors allowlist correspond exactement au motif que produit une exfiltration de données, et c'est ce que visent les exigences PCI DSS côté client.

Distinguer une mise à jour de prestataire d'une injection

Au premier coup d'œil, les deux se ressemblent. Deux éléments les séparent : le changement coïncide avec une release du prestataire que vous pouvez confirmer par vous-même, et la destination correspond à une infrastructure que ce prestataire exploite réellement.

Si aucun des deux ne se vérifie, traitez le cas comme un incident plutôt que comme un trou de configuration.

Étapes suivantes

On this page