CentralCSP
Outils

Vérificateur de reporting

Lisez les headers de reporting, résolvez chaque point de collecte, et voyez quelles politiques livrent des reports et lesquelles sont perdues en silence.

Dernière mise à jour:

Le vérificateur de reporting récupère une page en production, lit ses headers de reporting, et montre où chaque politique navigateur envoie ses violations. Il nomme les points de collecte (endpoints) que la réponse déclare, marque ceux vers lesquels rien ne pointe, et liste chaque politique présente qui ne reporte nulle part.

La collecte échoue en silence. Une politique avec une faute de frappe dans le nom de son point de collecte s'applique quand même, bloque quand même, et n'envoie quand même rien. Cet outil est le moyen de s'en apercevoir sans attendre des reports qui n'arriveront jamais.

Vérifier un site

  1. Ouvrez Outils > Vérificateur de reporting.
  2. Saisissez l'adresse, par exemple example.com.
  3. Laissez Suivre les redirections activé, sauf si vous voulez la réponse à cette URL exacte.
  4. Sélectionnez Vérifier le reporting.

Lire l'onglet Collecte

Le score et les constats fonctionnent comme dans les autres scanners, tels que décrits dans la vue d'ensemble des outils. Ce qui est propre à cet outil, c'est l'onglet Collecte, qui contient deux tableaux.

Points de collecte

Une ligne par point de collecte que la réponse déclare.

ColonneSignification
Point de collecteLe nom sous lequel le point de collecte est déclaré, par exemple default
URLOù sont envoyés les reports pour ce nom
StatutUtilisé si au moins une politique pointe dessus, Inutilisé sinon
Déclaré dansQuel header l'a déclaré, reporting-endpoints ou report-to

Un point de collecte Inutilisé est du poids mort, et en général le signe qu'une politique nomme un point de collecte différent de celui que vous avez configuré.

La colonne Déclaré dans est l'endroit où une configuration héritée se voit. Reporting-Endpoints est le header actuel. Report-To est le header déprécié, et il reste le seul header depuis lequel Network Error Logging lit son point de collecte, un site qui utilise NEL garde donc les deux.

Fonctionnalités reportées

Une ligne par politique que la réponse porte.

ColonneSignification
FonctionnalitéLa politique, par exemple Content-Security-Policy ou le reporting des hashes de scripts CSP
PrésentSi la réponse envoie la politique
Envoie versL'URL du point de collecte vers lequel ses violations aboutissent, ou vide si elle ne reporte nulle part
ModeBloqué si la politique bloque, Signalé si elle ne fait que reporter

Le vérificateur couvre Content-Security-Policy, le reporting des hashes de scripts CSP, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Permissions-Policy, Document-Policy, Integrity-Policy, Connection-Allowlist et Network Error Logging.

Ce que les trois états vous disent

Lire les deux tableaux ensemble donne une réponse parmi trois pour chaque politique.

  • Présente et pointant vers un point de collecte utilisé. Les reports sont bien livrés. Regardez ensuite la colonne Mode, parce qu'une politique Report-Only remonte sans bloquer.
  • Présente avec un Envoie vers vide. La politique est active et ses violations ne vont nulle part. Ajoutez une directive report-to qui nomme un point de collecte que vous avez déclaré.
  • Manquant. La politique n'est pas envoyée du tout, il n'y a donc rien à reporter.

Une ligne Signalé sur plusieurs politiques est un état courant et délibéré pendant un déploiement progressif. Cela devient un constat parce que signalé n'est pas bloqué, et un déploiement laissé à moitié fini ressemble exactement à la même chose vu de l'extérieur.

Vérifier votre propre point de collecte

Quand vous pointez un site vers CentralCSP, la même vérification tourne derrière Connecter votre site pour confirmer que vos headers nous parviennent. Lancer l'outil à la main est le moyen de revérifier plus tard, après qu'un changement de CDN ou une montée de version de framework a réécrit vos headers.

Étapes suivantes

On this page