Connecter votre site

Copiez les headers que CentralCSP génère pour votre site web, déployez-les, et vérifiez que le premier report arrive. Trois méthodes, une recommandée.

La page Configuration contient tout ce dont vous avez besoin pour commencer à collecter : l'URL de l'endpoint de ce site web, un bloc de headers généré selon votre plan, et une vérification qui confirme que les reports arrivent.

Il vous faut le rôle Gestionnaire ou supérieur sur le site web pour réserver un sous-domaine. Copier et déployer les headers ne demande rien de plus qu'un accès en lecture, puisque le travail se fait sur votre propre infrastructure.

Copiez les headers

Sous Configurez votre application, choisissez la méthode qui correspond à votre stack et sélectionnez Copier les headers. Utilisez Reporting-Endpoints sauf raison précise de faire autrement.

Le bloc généré ne contient que les politiques que votre plan peut réellement ingérer, il est donc plus court sur certains plans que sur d'autres. Déployez-le tel quel et chaque type de report accordé commence à arriver sans rien appliquer.

Deux headers font l'essentiel du travail. Le premier déclare où vont les reports :

Reporting-Endpoints: default="https://<ENDPOINT_ID>.report.centralcsp.com"

Le second est la politique qui commence à en produire :

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'report-sha256';
  report-uri https://<ENDPOINT_ID>.report.centralcsp.com;
  report-to default

Utilisez votre propre URL d'endpoint

<ENDPOINT_ID> est un espace réservé. Votre URL d'endpoint est unique à ce site web, alors copiez-la depuis votre page Configuration plutôt que de la recopier d'ici.

Gardez report-sha256 dans script-src

La source 'report-sha256' est ce qui pousse les navigateurs à reporter un hash de chaque script qu'ils chargent. C'est ce flux qui alimente l'inventaire de scripts et votre revue de scripts PCI DSS. Retirez-la et le suivi de conformité n'a plus rien à exploiter.

Configurez votre application, avec Reporting-Endpoints, Report-To et report-uri en onglets, le premier sélectionné et marqué Recommandé, et les headers générés en dessous

Ce que contient le reste du bloc

Chaque ligne restante est une politique dans sa variante de reporting, toutes pointant vers le même groupe default. Vous pouvez toutes les déployer d'un coup ou les ajouter au fil de l'eau, puisque chacune est indépendante.

Header	Commence à collecter
`Integrity-Policy-Report-Only`	Les scripts chargés sans métadonnées d'intégrité
`Permissions-Policy-Report-Only`	L'usage de la caméra, du micro et de la géolocalisation
`Document-Policy-Report-Only`	Les appels à `document.write`
`Cross-Origin-Opener-Policy-Report-Only`	Les interactions entre fenêtres et popups
`Cross-Origin-Embedder-Policy-Report-Only`	Les ressources cross-origin qui ne se sont pas déclarées
`Report-To` et `NEL`	Les requêtes en échec vers votre site

Deux détails surprennent souvent. Report-To apparaît même dans le bloc Reporting-Endpoints, parce que Network Error Logging est antérieur au header plus récent et ne comprend que l'ancien. Et la ligne CSP porte à la fois report-uri et report-to, parce que report-uri est déprécié mais reste le seul mécanisme honoré par certains navigateurs. Tout navigateur qui comprend report-to l'ignore, garder les deux ne coûte donc rien.

Report-To

La version précédente de la Reporting API, remplacée par Reporting-Endpoints mais encore honorée par certains navigateurs. Les mêmes politiques Report-Only s'appliquent, déclarées cette fois contre un groupe Report-To :

Report-To: {"group":"default","max_age":10886400,"endpoints":[{"url":"https://<ENDPOINT_ID>.report.centralcsp.com"}]}

Ne l'utilisez que si vous avez une raison précise de viser des navigateurs qui n'ont jamais implémenté Reporting-Endpoints.

report-uri

Un recours réservé à la Content Security Policy pour les navigateurs sans support de la Reporting API. La directive report-uri poste les violations directement vers l'endpoint :

Content-Security-Policy: default-src 'self'; report-uri https://<ENDPOINT_ID>.report.centralcsp.com

report-uri ne collecte que les violations CSP

Cette méthode ne livre rien d'autre que des reports de violation CSP. L'inventaire de scripts, la conformité PCI DSS et tous les autres types de report exigent la configuration Reporting-Endpoints ou Report-To.

Déployez les headers

Ajoutez-les à chaque réponse HTML que votre site renvoie. Ils doivent être sur la réponse du document ; les mettre uniquement sur les ressources ne collecte rien.

nginx.conf

add_header Reporting-Endpoints 'default="https://<ENDPOINT_ID>.report.centralcsp.com"' always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'report-sha256'; report-to default" always;

Votre site doit être servi en HTTPS. La Reporting API ne livre rien depuis une page en HTTP simple, et si une partie de votre parc est encore en HTTP, c'est presque toujours la raison des reports manquants.

Vérifiez

Ouvrez votre site en HTTPS, parcourez une page ou deux, puis sélectionnez Vérifier la configuration.

Les navigateurs groupent les reports par lots au lieu de les envoyer immédiatement, comptez donc jusqu'à une minute avant d'en conclure quoi que ce soit.

Si rien n'arrive, déroulez ceci dans l'ordre :

La page est servie en HTTPS.
Les headers sont présents sur la réponse du document HTML. Regardez l'onglet Réseau du navigateur, pas votre fichier de configuration.
L'URL de l'endpoint correspond exactement à celle de cette page.
Sous Paramètres > Ingestion, Origines autorisées est vide ou inclut l'origine depuis laquelle vous testez.
Votre espace de travail n'a pas atteint sa limite mensuelle de reports, qui arrête l'ingestion partout jusqu'à la remise à zéro.

Pour l'étape 2 sur un environnement où vous ne pouvez pas ouvrir les devtools, le vérificateur de configuration de la Reporting API récupère n'importe quelle URL publique et affiche ses headers Reporting-Endpoints et Report-To, ainsi que les politiques qui pointent vers un endpoint nommé.