# Connecter votre site (/fr/docs/platform/websites/connect-your-site) 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 [#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 : ```http Reporting-Endpoints: default="https://.report.centralcsp.com" ``` Le second est la politique qui commence à en produire : ```http Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'report-sha256'; report-uri https://.report.centralcsp.com; report-to default ``` `` 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. 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 [#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 [#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` : ```http Report-To: {"group":"default","max_age":10886400,"endpoints":[{"url":"https://.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 [#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 : ```http Content-Security-Policy: default-src 'self'; report-uri https://.report.centralcsp.com ``` 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 [#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 title="nginx.conf" add_header Reporting-Endpoints 'default="https://.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 [#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 : 1. La page est servie en HTTPS. 2. Les headers sont présents sur la réponse du document HTML. Regardez l'onglet Réseau du navigateur, pas votre fichier de configuration. 3. L'URL de l'endpoint correspond exactement à celle de cette page. 4. Sous **Paramètres** > **Ingestion**, **Origines autorisées** est vide ou inclut l'origine depuis laquelle vous testez. 5. 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](/tools/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é. ## Étapes suivantes [#étapes-suivantes] * [Sous-domaine personnalisé](/fr/docs/platform/websites/custom-subdomain) * [Filtres d'ingestion](/fr/docs/platform/websites/reporting-settings) * [Référence du header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) * [Référence du header Report-To](/fr/docs/web-security/reporting-api/headers/report-to)