Quickstart

Ce guide vous mène d'un espace de travail vide jusqu'aux reports qui arrivent dans le dashboard. Rien de ce qui suit n'applique une politique, vous pouvez donc l'exécuter en production sans changer le comportement d'une seule page.

Prérequis

• Un compte CentralCSP et un espace de travail. L'inscription crée votre premier espace de travail.
• Le droit de définir des headers de réponse HTTP sur le site, au niveau du serveur web, du CDN ou du framework applicatif.
• Le site servi en HTTPS. La Reporting API ne livre que depuis un contexte sécurisé.

1. Ajoutez votre site web

Ouvrez Sites web et sélectionnez Ajouter un site web. L'assistant compte quatre étapes.

1. Détails. Donnez un nom au site et son URL publique. Vous pouvez aussi définir une limite de consommation, qui arrête l'ingestion pour ce site une fois le nombre choisi atteint.
2. Reporting. Choisissez les types de report à collecter et la façon de filtrer ce qui est stocké.
3. Accès. Donnez à des personnes ou à des groupes l'accès à ce site web.
4. Récapitulatif. Confirmez et créez.

Seuls le nom et l'URL sont obligatoires. Tous les autres réglages restent modifiables ensuite dans les Paramètres du site web, alors gardez les valeurs par défaut si vous hésitez encore.

2. Copiez vos headers de reporting

Ouvrez le nouveau site web et allez sur Configuration. CentralCSP a généré une URL de collecte qui n'appartient qu'à ce site web, affichée sous Endpoint de reporting.

Sous Configurez votre application, choisissez la méthode qui correspond à votre stack. Reporting-Endpoints est la méthode moderne, celle à utiliser sauf raison particulière.

Le bloc généré déclare l'endpoint une fois, puis pointe chaque fonctionnalité de reporting vers lui. Déclarez d'abord l'endpoint :

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

Pointez ensuite une politique vers cet endpoint nommé. Chaque politique est générée dans sa variante Report-Only, pour que les navigateurs signalent les violations sans rien bloquer :

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

Le bloc inclut aussi report-uri à côté de report-to. C'est volontaire : report-uri est déprécié mais reste le seul mécanisme honoré par certains navigateurs, et les navigateurs qui comprennent les deux ignorent report-uri dès que report-to est présent. Garder les deux ne coûte rien et élargit la couverture.

3. Déployez les headers

Ajoutez les headers à chaque réponse HTML que votre site renvoie. L'endroit où cela se passe dépend de votre stack, mais la règle est la même partout : les headers doivent être sur la réponse du document, pas seulement sur les ressources.

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;

Si vous voulez commencer par la CSP seule, déployez les deux premiers headers et ajoutez le reste plus tard. Chaque politique est indépendante.

4. Vérifiez que le premier report arrive

De retour sur Configuration, la section Vérifier la configuration affiche un compteur en direct des reports reçus. Ouvrez votre site en HTTPS dans un navigateur, cliquez sur une page ou deux, puis sélectionnez Vérifier la configuration.

Les reports sont regroupés par lots par le navigateur plutôt qu'envoyés instantanément, comptez donc jusqu'à une minute. La Progression de la configuration, dans la colonne de droite, passe au vert sur les trois étapes dès qu'un report arrive.

Si rien n'arrive, vérifiez dans cet ordre :

• La page est servie en HTTPS. En HTTP simple, aucun report n'est livré.
• Les headers sont présents sur la réponse du document HTML. Regardez l'onglet Réseau, pas votre fichier de configuration.
• L'URL de l'endpoint correspond exactement à celle de la page Configuration.
• Sous Paramètres > Ingestion, Origines autorisées est vide ou contient bien l'origine depuis laquelle vous testez.

Le vérificateur de configuration de la Reporting API répond au deuxième point sans passer par le navigateur : donnez-lui votre URL et il liste les headers de reporting que le site renvoie réellement.

5. Faites ensuite ces trois choses

Vous avez maintenant un site qui collecte des reports sans rien appliquer. Avant que les données ne s'accumulent :

• Coupez le bruit des extensions: Sous Paramètres > Ingestion, activez Ignorer les reports des extensions de navigateur. L'option est désactivée par défaut, et les scripts injectés par les extensions sont la plus grosse source de violations que vous ne pouvez pas corriger. Voir Filtres d'ingestion.
• Traitez la page CSP une directive à la fois: Le premier lot est bruyant par construction, parce que la politique générée n'autorise rien au-delà de votre propre origine. Cette liste est un inventaire, pas une liste d'incidents. Voir Violations CSP.
• Définissez le périmètre des pages de paiement, si des données de carte sont en jeu, avant de passer en revue le moindre script. Voir PCI DSS.

Étapes suivantes

• Reports
• Sites web
• Référence du header Reporting-Endpoints