Connection allowlist
Les connexions que vos pages ont tentées en dehors de la liste. Construisez la liste à partir du trafic observé, puis resserrez-la.
Dernière mise à jour:
Les tentatives de connexion qui sortaient 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.
Colonnes
| Colonne | Signification |
|---|---|
| Type de connexion | Le genre de connexion tentée |
| Origine de la connexion | Vers où elle allait |
| Origine du document | 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 |
L'URL de connexion complète et l'entrée d'allowlist qui s'appliquait sont également enregistrées.
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. Faites tourner sur un cycle d'activité normal, au moins deux semaines, pour que les connexions périodiques apparaissent. Les batchs hebdomadaires et les flux de fin de mois sont ceux qu'une fenêtre courte rate.
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.
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 fait que le changement coïncide avec une release du prestataire que vous pouvez confirmer de façon indépendante, et le fait que la destination corresponde à 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.