# Report-Only (/fr/docs/web-security/policies/content-security-policy/report-only) Le header `Content-Security-Policy-Report-Only` demande au navigateur de vérifier une politique de sécurité du contenu (CSP) et de signaler chaque violation, sans rien bloquer. Vous voyez exactement ce qu'une politique casserait avant qu'elle ne le casse. C'est ce qui en fait la façon sûre de déployer ou de resserrer une politique sur un site en production. Une politique candidate en cours de test, associée à l'endpoint qui reçoit ses rapports : ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint ``` ## Aperçu rapide [#aperçu-rapide] Une politique Report-Only s'écrit exactement comme une politique appliquée. La seule différence est le nom du header et la disposition qui en résulte. Avec `Content-Security-Policy-Report-Only`, la disposition est `report` : le navigateur charge la ressource et envoie un [rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation) au lieu d'appliquer le comportement `enforce` du header [`Content-Security-Policy`](/fr/docs/web-security/policies/content-security-policy). ```http Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; object-src 'none'; base-uri 'none'; report-to csp-endpoint ``` Une politique report-only n'est utile que si elle a quelque part où envoyer ses rapports. Associez-la à une directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) (et à l'ancienne directive [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri) seulement si vous devez couvrir de vieilles versions de navigateurs) pour que les violations atteignent un endpoint que vous contrôlez. ## Valeurs [#valeurs] La valeur du header est une CSP, la même liste de directives séparées par des points-virgules que vous mettriez dans une politique appliquée. Chaque directive CSP est valide ici. Les directives qui comptent vraiment en Report-Only sont celles de reporting, puisque rien n'est appliqué. | Partie | Statut | Ce que ça fait | | -------------------------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------- | | La liste de directives | ✅ Bon | Définit la politique que le navigateur évalue contre la page. | | [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) | ✅ Bon | Nomme le groupe d'endpoints qui reçoit les rapports de violation. | | [`report-uri`](/fr/docs/web-security/policies/content-security-policy/directives/report-uri) | ⚠️ Déprécié | Cible de reporting historique, conservée uniquement pour les anciennes versions de navigateurs non mises à jour. | Une réponse peut transporter les deux headers à la fois. Envoyez un `Content-Security-Policy` appliqué pour la politique en laquelle vous avez confiance aujourd'hui, et un `Content-Security-Policy-Report-Only` séparé pour la politique plus stricte que vous testez. Le navigateur évalue chacune indépendamment et signale la report-only sans toucher à la page. ## Valeurs non sûres à éviter [#valeurs-non-sûres-à-éviter] Une politique Report-Only ne protège jamais rien, donc elle n'a pas de valeurs non sûres en propre. L'erreur est de la traiter comme une protection. Ne livrer que `Content-Security-Policy-Report-Only` en production signifie que le navigateur signale les attaques mais n'en bloque aucune. Le script inline d'un attaquant s'exécute quand même. Utilisez Report-Only pour apprendre quoi appliquer, puis déplacez la politique validée vers le header d'application `Content-Security-Policy`. Une seconde erreur est une politique report-only sans aucune directive de reporting. Sans `report-to` ni `report-uri`, le navigateur évalue la politique et jette chaque violation, donc vous n'apprenez rien. ## Pourquoi ce header existe [#pourquoi-ce-header-existe] Une vraie politique casse presque toujours quelque chose au premier essai : un script inline, un widget tiers, une image `data:`. Appliquer une politique non testée met le site à terre. Report-Only a été introduit pour que vous puissiez déployer une politique candidate, regarder les violations arriver depuis le vrai trafic, corriger les manques, et seulement ensuite l'appliquer. Il transforme le déploiement d'une CSP d'un pari en une mesure. ## Contre quoi cela protège [#contre-quoi-cela-protège] Le header lui-même ne bloque rien, donc il ne protège rien directement. Sa valeur de sécurité est indirecte. Il vous permet d'atteindre en sécurité un [`Content-Security-Policy`](/fr/docs/web-security/policies/content-security-policy) strict et appliqué. Plus vite vous validez une politique serrée, plus tôt vous obtenez une vraie protection contre le cross-site scripting (XSS) et l'injection. Collecter les violations report-only dans [CentralCSP](/platform/csp-builder) vous montre exactement quelles directives ajuster avant de basculer vers l'application. ## Contournements et limitations connus [#contournements-et-limitations-connus] Une balise `` ne peut pas livrer de politique Report-Only. L'élément meta ne prend en charge que le `Content-Security-Policy` d'application, donc Report-Only est exclusivement un header de réponse HTTP. Il en va de même pour les directives de reporting (`report-to`, `report-uri`), qu'une balise meta ne peut pas non plus définir. Les violations Report-Only sont signalées par politique, donc une politique candidate bruyante peut générer un gros volume de rapports sur une page à fort trafic. Échantillonnez-les et triez-les plutôt que de lire du JSON brut. ## Risques d'une mauvaise configuration [#risques-dune-mauvaise-configuration] Le risque dominant est de confondre les deux headers. Laisser une politique stricte en Report-Only pour toujours donne un faux sentiment de sécurité sans aucune application, tandis que promouvoir une politique non testée directement vers `Content-Security-Policy` casse la page. Validez en Report-Only, puis appliquez. ## Recommandation [#recommandation] Chaque fois que vous resserrez une politique, faites tourner la candidate en Report-Only à côté de la politique appliquée, et pointez les deux vers `report-to` avec une déclaration [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints). ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy-Report-Only: script-src 'nonce-r4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'none'; report-to csp-endpoint ``` Tous les moteurs actuels livrent désormais les rapports `report-to`, donc cette paire est le transport principal ; n'ajoutez `report-uri` que pour les traînes de vieilles versions. Le déploiement par étapes via Report-Only est l'approche que recommande le [guide de CSP stricte de web.dev](https://web.dev/articles/strict-csp). ## Comment la mettre en place [#comment-la-mettre-en-place] 1. Envoyez `Content-Security-Policy-Report-Only` avec votre politique candidate et une directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) qui nomme un groupe d'endpoints. 2. Déclarez ce groupe avec le header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) pour que le navigateur sache où envoyer les rapports. ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; object-src 'none'; base-uri 'none'; report-to csp-endpoint ``` 3. Surveillez les [rapports de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation), corrigez les casses légitimes, et une fois la politique propre, déplacez-la vers le header d'application `Content-Security-Policy`. Le [vérificateur de configuration Reporting API](/tools/reporting-api) confirme que le câblage de votre endpoint fonctionne avant que vous ne comptiez sur les rapports. ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] Largement pris en charge. `Content-Security-Policy-Report-Only` fonctionne dans les navigateurs modernes. Le transport `report-to` plus [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) est désormais cross-browser lui aussi, pris en charge dans les versions actuelles de Chrome, Safari et Firefox (Firefox a été le dernier moteur à l'ajouter). Ne gardez `report-uri` que pour couvrir les anciennes versions de navigateurs non mises à jour. ## Voir aussi [#voir-aussi] * [Content-Security-Policy](/fr/docs/web-security/policies/content-security-policy) * [Directive report-to](/fr/docs/web-security/policies/content-security-policy/directives/report-to) * [Directive report-uri](/fr/docs/web-security/policies/content-security-policy/directives/report-uri) * [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) * [Rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation) * [CSP enforce vs report-only](/fr/blog/csp-enforce-vs-report-only) * [report-uri vs report-to](/fr/blog/report-uri-vs-report-to) ## Sources [#sources] * [MDN, Content-Security-Policy-Report-Only](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy-Report-Only) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/)