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 :

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

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 au lieu d'appliquer le comportement enforce du header Content-Security-Policy.

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 (et à l'ancienne directive report-uri seulement si vous devez couvrir de vieilles versions de navigateurs) pour que les violations atteignent un endpoint que vous contrôlez.

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é.

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

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

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

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 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 vous montre exactement quelles directives ajuster avant de basculer vers l'application.

Contournements et limitations connus

Une balise <meta http-equiv> 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

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

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.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

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.

Comment la mettre en place

1. Envoyez Content-Security-Policy-Report-Only avec votre politique candidate et une directive report-to qui nomme un groupe d'endpoints.
2. Déclarez ce groupe avec le header Reporting-Endpoints pour que le navigateur sache où envoyer les rapports.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

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, 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 confirme que le câblage de votre endpoint fonctionne avant que vous ne comptiez sur les rapports.

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 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

• Content-Security-Policy
• Directive report-to
• Directive report-uri
• Header Reporting-Endpoints
• Rapport de violation CSP
• CSP enforce vs report-only
• report-uri vs report-to

Sources

• MDN, Content-Security-Policy-Report-Only
• W3C, Content Security Policy Level 3
• W3C, Reporting API