Pourquoi le mode report-only diffère du mode d’application dans Content Security Policy

By Mirko Peters · 2026-04-23

Si la sécurité web vous tient à cœur, comprendre la différence entre les modes « report-only » et « d’application » dans Content Security Policy (CSP)…

Automatically translated with AI from the original post. Read the English original

Si la sécurité web vous tient à cœur, comprendre la différence entre les modes « report-only » et « d’application » dans Content Security Policy (CSP) n’est pas un simple détail : c’est l’essentiel. Le mode report-only vous permet de voir ce que votre stratégie bloquerait, sans rien arrêter réellement, et transforme votre site en véritable terrain d’essai pour la sécurité. Le mode d’application, lui, ne plaisante pas : il bloque tout ce qui contrevient à votre stratégie et verrouille votre site en temps réel.

Cet article détaille pourquoi ces modes sont importants, leurs effets sur le navigateur et sur l’expérience utilisateur, et la manière de passer d’une simple surveillance à une protection effective. Il s’adresse plus particulièrement aux professionnels de la sécurité et aux développeurs gravitant autour de Microsoft qui souhaitent configurer correctement leur CSP : définitions, techniques pratiques, bonnes pratiques pour un déploiement sécurisé et une conformité efficace.

Comprendre les modes de CSP et leur impact

Avant de déployer des en-têtes CSP à tout-va, il faut bien maîtriser les deux modes principaux de CSP : report-only et d’application. Ces modes sont plus que de simples paramètres : ils déterminent la manière dont les navigateurs modernes protègent (ou se contentent d’observer) les frontières de sécurité de votre application web. Votre choix influe directement sur le niveau de risque de votre site, sur votre capacité d’audit et sur la fluidité de votre déploiement, en particulier dans les grands environnements Microsoft ou les architectures multicloud.

Les modes CSP ont été conçus pour offrir de la souplesse aux équipes web. Le mode report-only constitue le point d’entrée en douceur : il vous permet de surveiller les problèmes sans risquer de casser quoi que ce soit pour les utilisateurs. Il facilite l’évaluation des risques, aide à repérer les lacunes de la stratégie et permet d’identifier du code hérité ou des comportements inattendus de tiers, tout en maintenant votre application pleinement opérationnelle.

Le mode d’application est l’élément central : il demande au navigateur d’exécuter réellement vos instructions. Tout contenu non conforme à votre stratégie est bloqué immédiatement, ce qui réduit fortement la surface d’attaque face à des menaces comme le cross-site scripting ou les scripts tiers malveillants. Mais cela signifie aussi que des erreurs ou une stratégie incomplète peuvent interrompre votre application si les tests et la mise en production ne sont pas menés avec soin.

L’idée derrière la coexistence des deux modes est simple : laisser les développeurs et les équipes sécurité affiner leurs règles en conditions réelles avant de passer à l’action. Considérez cela comme des roulettes d’apprentissage pour la sécurité de votre application, avec une ligne d’arrivée au-delà de laquelle vous basculez vers l’application complète. Nous verrons ensuite comment le mode report-only vous fournit ce retour d’expérience réel et ce qui change lorsque le mode d’application entre en jeu.

Fonctionnement de Content-Security-Policy-Report-Only pour la remontée des violations

Le mode report-only est la façon qu’a CSP de vous laisser observer depuis les gradins avant de descendre sur le terrain. Lorsque vous utilisez l’en-tête HTTP Content-Security-Policy-Report-Only, vous demandez au navigateur de « surveiller les violations, sans rien bloquer, simplement les signaler ». Vous recevez ainsi un flux de rapports de violation envoyés au point de terminaison que vous avez défini, avec un récapitulatif complet de ce qui serait bloqué si la stratégie était appliquée.

Les navigateurs envoient ces rapports de violation (souvent au format JSON) dès qu’une ressource enfreint vos règles CSP. Par exemple, si une page tente de charger un script depuis une source non approuvée, aucun script n’est bloqué en mode report-only, mais vous recevez tout de même une alerte avec des détails tels que l’URL en cause, la directive non respectée et, parfois, un extrait du code suspect.

Ce mode est précieux pour l’évaluation des risques et les tests sans danger. Vous pouvez déployer de nouvelles règles sur un parc d’applications web, surveiller ce qui se déclenche et ajuster la stratégie sur la base de données réelles plutôt que de simples suppositions. Si vous exploitez des systèmes hérités ou des flux métier critiques, vous ne risquez ni interruption de site ni appels au support en allant trop vite.

Le mode report-only facilite également les déploiements progressifs. Commencez en mode ouvert, identifiez ce qui doit être ajusté, puis resserrez la sécurité étape par étape. Il permet de découvrir les problèmes liés aux scripts tiers, au contenu issu de CDN ou au JavaScript obfusqué, qui pourraient sinon rester cachés jusqu’à ce que l’application provoque une défaillance spectaculaire. De plus, c’est un atout pour la conformité : vous disposez de la preuve que vous surveillez activement votre environnement, ce qui peut faciliter les audits lorsque votre organisation doit démontrer sa diligence.

Comment le mode d’application renforce la sécurité

Le mode appliqué (enforced) est le moment où votre stratégie CSP cesse d’être une simple suggestion pour devenir une règle. Lorsque vous utilisez l’en-tête Content-Security-Policy, les navigateurs bloquent effectivement tout contenu qui ne respecte pas vos directives : pas d’avertissement, seulement une action.

Ce mode renforce considérablement votre application web face à des attaques telles que le XSS et l’injection de scripts non autorisés. Attention toutefois : si votre stratégie n’est pas prête, vous pourriez bloquer par inadvertance des ressources nécessaires et altérer le fonctionnement du site. Tester d’abord en mode rapport seul est la démarche judicieuse. En fin de compte, le mode appliqué est ce qui transforme une stratégie théorique en protection concrète, et c’est la référence en matière de sécurité web renforcée.

Mise en place des rapports avec les points de terminaison report-uri et report-to

La configuration des rapports est ce qui donne à votre stratégie CSP de réelles capacités de contrôle, et un regard attentif sur son fonctionnement. CSP vous permet de spécifier un ou plusieurs points de terminaison (à l’aide de report-uri ou report-to) vers lesquels les navigateurs doivent envoyer les rapports de violation. Lorsqu’une violation se produit, le navigateur regroupe les détails, comme la ressource bloquée et la stratégie non respectée, dans un message JSON ou une requête HTTP POST, puis l’envoie à votre point de terminaison.

La directive report-uri est la méthode historique : vous indiquez une URL, et les navigateurs y envoient directement les rapports. Toutefois, pour plus de souplesse et des rapports plus riches, report-to est l’option plus récente et plus robuste, d’autant que les navigateurs étendent progressivement la prise en charge de l’API Reporting. report-to s’appuie sur un groupe nommé, capable de traiter différents types de rapports, et offre un meilleur contrôle du filtrage.

Lors de la configuration de ces points de terminaison, il est indispensable de les sécuriser : HTTPS, contrôles d’accès et surveillance des pics inhabituels, qui peuvent signaler une attaque ou une stratégie défaillante. N’oubliez pas non plus la confidentialité : les rapports peuvent contenir des URL, voire des extraits de script incriminé. Vous devez donc être prêt à épurer les informations sensibles avant de les stocker ou de les partager, en tenant compte de réglementations telles que le RGPD et le CCPA.

L’intérêt majeur réside dans la visibilité. Grâce à des rapports correctement configurés, vous disposez d’un flux en temps réel des endroits où votre stratégie détecte des violations. Vous pouvez ainsi ajuster, affiner et passer en toute sécurité au mode appliqué, sans mauvaise surprise. Ce niveau de supervision est essentiel, que vous gériez une application unique ou un environnement Microsoft 365 étendu.

Comprendre la syntaxe et les directives CSP pour concevoir une stratégie efficace

Rédiger un en-tête CSP solide n’a rien de sorcier, mais il exige de la rigueur, surtout lorsqu’il s’agit de jongler avec des applications complexes et des intégrations cloud Microsoft. Au fondement, une stratégie CSP est une liste structurée de directives, chacune indiquant aux navigateurs ce qui est autorisé et ce qui ne l’est pas. Ces stratégies sont transmises via des en-têtes HTTP, généralement Content-Security-Policy ou Content-Security-Policy-Report-Only, sous la forme de chaînes de règles séparées par des points-virgules.

Le cœur de votre stratégie repose sur des directives clés telles que default-src, script-src et img-src. default-src sert de valeur de repli : si un type de contenu ne dispose pas de sa propre règle, le navigateur consulte celle-ci. script-src et img-src ciblent respectivement les scripts et les images, et vous permettent de contrôler finement les sources de confiance, qu’il s’agisse de vos domaines, de réseaux de diffusion de contenu (CDN) approuvés ou, pourquoi pas, d’un ou deux conteneurs de stockage Azure Blob.

La syntaxe compte. Chaque directive énumère les valeurs autorisées : URL, schémas tels que ‘https:’, ou mots-clés tels que ‘self’. Si vous autorisez les scripts en ligne (parfois nécessaires pour du code hérité), vous pourriez avoir besoin de ‘unsafe-inline’. Attention toutefois : cela affaiblit votre protection, sauf si vous recourez à des empreintes (hashes) de scripts ou à des nonces pour une validation supplémentaire.

Pour les professionnels Microsoft, portez attention à la manière dont les services cloud injectent leurs dépendances. Les applications d’entreprise complexes chargent souvent leurs ressources dynamiquement, utilisent des service workers ou intègrent des fournisseurs tiers. Votre stratégie doit trouver l’équilibre entre rigueur, pour la sécurité, et souplesse, pour que l’application fonctionne. Bien poser les bases dès le départ rendra les tests nettement plus fluides par la suite.

Bonnes pratiques pour passer du mode rapport seul au mode appliqué

La démarche la plus judicieuse avec CSP consiste à commencer en mode rapport seul, à collecter les données, puis seulement à activer l’application de la stratégie. Ne considérez pas le déploiement de CSP comme une liste de contrôle ponctuelle. Adoptez plutôt une approche de projet par étapes, dans laquelle vous surveillez, ajustez et renforcez progressivement vos stratégies, afin d’éviter de perturber les fonctionnalités utilisées par vos utilisateurs finaux ou les processus métier critiques.

Commencez par déployer une stratégie large mais raisonnable en mode report-only. Collectez les rapports de violation et, idéalement, agrégez-les à l’aide de tableaux de bord ou d’outils d’analyse afin de faire ressortir les contrevenants récurrents. Cela vous permet de faire le tri dans le bruit, d’écarter les faux positifs et de vous concentrer sur les risques réels. Si vous constatez un grand nombre de rapports routiniers ou redondants (ce qui est courant), ajustez vos analyses de journaux ou écrivez des filtres de script selon l’user agent ou le type de ressource.

Une fois que le volume de violations diminue et que la plupart des problèmes sont résolus, commencez à appliquer les règles progressivement tout en surveillant l’apparition de nouveaux dysfonctionnements. Placez en premier en mode application les sections à haut risque et à faible trafic, puis surveillez-les. Si tout se passe bien, étendez l’application au reste du projet. Documentez les modifications et recueillez les retours des développeurs et des parties prenantes tout au long du processus, en particulier dans les applications Microsoft 365 ou Azure complexes, où les couches d’accès conditionnel ajoutent des difficultés supplémentaires. Pour les stratégies et les plans de déploiement associés, je vous invite à consulter ce guide sur les problèmes de confiance liés à l’accès conditionnel ainsi que cet épisode consacré à la sécurité des identités.

Ne sous-estimez jamais les tests. Utilisez les outils de développement des navigateurs, les testeurs de statut CSP et même des analyses automatisées dans vos pipelines CI/CD pour vérifier que vos stratégies fonctionnent comme prévu. Le but final ? Une application verrouillée, conforme et résiliente, protégée par une stratégie affinée dans des conditions réelles, et non par de vains espoirs.

Exemples concrets de CSP en mode report-only et en mode appliqué

Rien ne rend la CSP plus concrète que des exemples réels. En mode report-only, vous pouvez utiliser un en-tête tel que : Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Cette configuration enregistre chaque violation sans perturber vos utilisateurs, ce qui en fait une solution idéale pour tester en production sans risque.

Comparons avec une stratégie appliquée : Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Ici, le navigateur bloque activement tout script ou toute image qui ne respecte pas les règles, protégeant immédiatement vos utilisateurs contre les contenus non approuvés.

En pratique, les organisations commencent par le mode report-only pour identifier les fournisseurs, scripts ou fonctionnalités métier qui cesseraient de fonctionner sous un verrouillage strict. Par exemple, le portail web d’une administration pourrait découvrir d’anciens scripts ou un CDN d’analyse marketing qui déclenche des violations répétées. Les équipes itèrent, ajoutent à la liste blanche les fournisseurs sûrs, puis appliquent la stratégie finalisée par étapes afin de limiter les perturbations.

Le passage du mode report-only au mode appliqué peut révéler des pièges cachés, en particulier avec les scripts tiers ou les contenus dynamiques. Les équipes rencontrent souvent des violations « fantômes », qui n’apparaissent que sur certains navigateurs ou dans des conditions précises. En s’appuyant sur les données réelles collectées pendant la phase report-only, elles ajustent la stratégie jusqu’à ce que l’application soit non seulement sécurisée, mais aussi stable pour tous les utilisateurs concernés.

Synthèse des principales différences entre les modes report-only et appliqué

• Comportement : Le mode report-only se contente de signaler les violations de stratégie, sans bloquer aucun contenu. Le mode appliqué bloque activement tout élément qui viole votre stratégie CSP.
• Objectif : Le mode report-only vous permet de tester et d’affiner vos stratégies sans aucun risque pour les utilisateurs. Le mode appliqué assure une protection réelle et rend vos règles de sécurité effectives.
• Impact sur les utilisateurs : Le mode report-only est invisible, les utilisateurs ne le remarquent jamais. Le mode appliqué peut bloquer des fonctionnalités ou des contenus si vos règles n’ont pas été testées au préalable.
• Cas d’usage : Le mode report-only est idéal pour les déploiements progressifs, l’analyse des risques et la vérification de la compatibilité avec les applications existantes. Le mode appliqué constitue l’étape finale pour obtenir une sécurité robuste et conforme.
• Conformité et risques : Le mode report-only facilite la surveillance et la documentation lors des audits, tandis que le mode appliqué empêche directement les violations de sécurité en temps réel.