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 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 ne sert à rien si elle n'a nulle 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 dont vous êtes sûr 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 rien, elle n'a donc pas de valeurs non sûres en propre. L'erreur est de la prendre pour une protection. N'envoyer que Content-Security-Policy-Report-Only en production, c'est laisser le navigateur signaler les attaques sans en bloquer une seule. Le script inline d'un attaquant s'exécute quand même. Servez-vous de Report-Only pour savoir quoi appliquer, puis basculez la politique validée dans le header d'application Content-Security-Policy.

La seconde erreur, c'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 : 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, voir les violations remonter du trafic réel, corriger les manques, et seulement ensuite l'appliquer. Il fait passer le déploiement d'une CSP du pari à la 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'arriver sans casse à 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 transmettre 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 principal est de confondre les deux headers. Laisser indéfiniment une politique stricte en Report-Only donne un faux sentiment de sécurité, puisque rien n'est appliqué ; à l'inverse, promouvoir une politique non testée directement dans 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 branchez les deux sur 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 envoient désormais les rapports report-to : cette paire est le transport principal, et report-uri ne sert plus qu'à couvrir les vieilles versions qui traînent. 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 ce qui casse légitimement, et une fois la politique propre, basculez-la dans le header d'application Content-Security-Policy. Le vérificateur de configuration Reporting API confirme que votre endpoint est bien branché 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