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 :

Colonnes
Le tableau des reports comporte ces colonnes :
| Colonne | Signification |
|---|---|
| Type de connexion | Le schéma de l'URL bloquée, par exemple https, ou webrtc pour une connexion WebRTC |
| Origine de la connexion | L'origine de l'URL bloquée, ou webrtc |
| Origine du document | L'origine de la page qui l'a tentée |
| Navigateurs | Les navigateurs qui l'ont signalée |
| Disposition | Appliqué signifie bloqué, Report-only signifie que cela l'aurait été |
| Reports | Les reports regroupés dans cette ligne |
| Dernière occurrence | L'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 connexionwss:sous son URLhttps:. Pour l'autoriser, listez l'originehttps:, jamais une originewss:. 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
preconnectbloqué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
Crashs
Les onglets qui sont morts sur vos pages. Des défaillances invisibles pour votre suivi des erreurs, et pourquoi la visibilité change la priorité.
COEP
Les ressources cross-origin qui ne se sont pas déclarées embarquables. Rarement corrigeables chez vous, ce qui change la façon de planifier une isolation.