Pourquoi le mode Report-Only se distingue du mode Enforced dans Content Security Policy

By Mirko Peters · 2026-04-23

Si vous prenez la sécurité web au sérieux, comprendre la différence entre les modes « report-only » et « enforced » de Content Security Policy…

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

Si vous prenez la sécurité web au sérieux, comprendre la différence entre les modes « report-only » et « enforced » de 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 fait de votre site une sorte de terrain d’essai pour la sécurité. Le mode enforced, lui, ne plaisante pas : il bloque tout ce qui contrevient à votre stratégie et verrouille votre site en temps réel.

Cet article explique pourquoi ces modes sont importants, ce qu’ils changent pour le navigateur et l’expérience utilisateur, et comment passer d’une simple surveillance à une protection réelle. Il s’adresse particulièrement aux professionnels de la sécurité et aux développeurs attachés à Microsoft qui veulent configurer correctement leur CSP : définitions, techniques pratiques et bonnes pratiques pour un déploiement sécurisé et une conformité intelligente.

Comprendre les modes de CSP et leur impact

Avant de distribuer des en-têtes CSP à tout-va, il faut bien maîtriser les deux modes principaux de CSP : report-only et enforced. 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 limites 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 le bon déroulement de votre déploiement, en particulier dans les grands environnements Microsoft ou les configurations multicloud.

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

Le mode enforced est l’élément central : il demande au navigateur d’appliquer réellement vos instructions. Si un contenu ne correspond pas à votre stratégie, il est bloqué, ce qui réduit immédiatement 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 des stratégies incomplètes peuvent interrompre votre application si les tests et l’adoption ne sont pas menés avec soin.

L’idée derrière la coexistence des deux modes est simple : laisser les équipes de développement et de 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 une application complète. Nous verrons ensuite précisément comment le mode report-only fournit ce retour d’expérience réel et ce qui change dès que le mode enforced entre en scène.

Content-Security-Policy-Report-Only : fonctionnement du signalement des violations

Le mode report-only permet à 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, mais de ne rien bloquer, simplement de les signaler ». Vous recevez ainsi un flux de rapports de violation envoyés à votre point de terminaison, 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 comme l’URL en cause, la directive violée et, parfois, un extrait du code suspect.

Ce mode est inestimable pour les évaluations de 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 à partir de données réelles, et non de simples suppositions. Si vous exploitez des systèmes hérités ou des flux métier critiques, vous évitez de risquer des interruptions de site ou des appels au support en allant trop vite.

Le mode report-only favorise aussi les déploiements progressifs. Commencez en mode ouvert, identifiez ce qui doit être ajusté, puis resserrez la sécurité étape par étape. Il permet aux équipes de détecter les problèmes liés aux scripts tiers, au contenu CDN ou au JavaScript obfusqué, qui resteraient sinon cachés jusqu’à ce que le mode enforced soit activé et provoque une défaillance spectaculaire. De plus, c’est un atout pour la conformité : vous disposez de la preuve que vous surveillez activement, ce qui peut faciliter les audits lorsque votre organisation doit démontrer sa diligence raisonnable.

Comment le mode enforced renforce la sécurité

Le mode d’application 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 réellement tout contenu qui ne respecte pas vos directives. Aucun avertissement, seulement une action.

Ce mode renforce considérablement votre application web face à des attaques comme le XSS ou l’injection de scripts non autorisés. Attention toutefois : si votre stratégie n’est pas prête, vous risquez de bloquer par accident des ressources nécessaires et de casser des fonctionnalités du site. Il est judicieux de commencer par tester en mode Report-Only. En définitive, le mode d’application transforme une stratégie théorique en protection concrète, ce qui en fait la référence en matière de sécurité web renforcée.

Mettre en place le reporting avec les points de terminaison Report-URI et Report-To

La mise en place du reporting donne à votre stratégie CSP de réelles capacités, ainsi qu’un regard attentif. CSP vous permet de spécifier un ou plusieurs points de terminaison (à l’aide de report-uri ou de report-to) vers lesquels les navigateurs doivent envoyer leurs rapports de violation. Lorsqu’une violation se produit, le navigateur regroupe les détails, comme la ressource bloquée et la stratégie en échec, 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 une souplesse moderne et un reporting plus riche, report-to constitue l’option la plus récente et la plus robuste, d’autant que les navigateurs étendent leur prise en charge de l’API Reporting. report-to s’appuie sur un groupe nommé, capable de gérer différents types de rapports, et offre un meilleur contrôle du filtrage.

Lors de la configuration de ces points de terminaison, veillez à les sécuriser : HTTPS, contrôles d’accès et surveillance des pics inattendus, 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 du script incriminé. Vous devez donc être prêt à supprimer les informations sensibles avant de les stocker ou de les partager, en restant attentif aux réglementations telles que le RGPD et le CCPA.

Le véritable atout réside dans la visibilité. Avec un reporting correctement configuré, 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, à terme, passer en mode d’application en toute sérénité, sans surprise. Ce niveau de supervision est indispensable, que vous gériez une application unique ou un environnement Microsoft 365 étendu.

Maîtriser la syntaxe et les directives CSP pour une conception efficace de la stratégie

Rédiger un en-tête CSP solide n’a rien de sorcier, mais cela exige de la rigueur, surtout lorsque l’on jongle avec des applications complexes et des intégrations aux services cloud de Microsoft. À la base, 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. Vous transmettez ces stratégies via des en-têtes HTTP, généralement Content-Security-Policy ou Content-Security-Policy-Report-Only, sous 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 comme 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 (vos domaines, les CDN de confiance et peut-être un ou deux objets blob Microsoft Azure).

La syntaxe compte. Chaque directive énumère les valeurs autorisées : des URL, des schémas comme ‘https:’ ou des mots-clés comme ‘self’. Si vous autorisez les scripts en ligne, parfois nécessaires pour du code hérité, vous pourriez avoir besoin de ‘unsafe-inline’. Restez prudent, car cela affaiblit votre protection, à moins d’utiliser des empreintes (hashes) ou des nonces de script 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 un équilibre entre rigueur, pour la sécurité, et souplesse, pour que l’application fonctionne. Posez correctement les bases dès le départ, et les tests seront nettement plus fluides par la suite.

Bonnes pratiques pour passer du mode Report-Only au mode d’application

La démarche la plus judicieuse avec CSP consiste à commencer en mode Report-Only, à collecter vos données, puis seulement à activer l’application. Ne considérez pas le déploiement de CSP comme une simple liste de contrôle à cocher une fois pour toutes. Abordez-le plutôt comme un projet par étapes, où vous surveillez, ajustez et durcissez progressivement vos stratégies afin d’éviter de perturber les 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 récidivistes. 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 de nombreux rapports routiniers ou redondants (ce qui est fréquent), affinez votre analyse de journaux ou écrivez des filtres de script selon l’agent utilisateur 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 nouvelles ruptures. Placez d’abord en application les sections à risque élevé et à faible trafic, puis surveillez. 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 connexes et les plans de déploiement, vous pouvez consulter ce guide sur les problèmes de confiance liés à l’accès conditionnel et cet épisode consacré à la sécurité des identités.

Ne sous-estimez jamais la phase de test. Utilisez les outils de développement du navigateur, les testeurs d’état 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 en conditions réelles et non par des vœux pieux.

Exemples concrets de CSP en modes Report-Only et appliqué

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

Comparez 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. Désormais, 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 afin de repérer quels fournisseurs, scripts ou fonctionnalités métier cesseraient de fonctionner sous un verrouillage de type mimic-lockdown. Par exemple, un portail gouvernemental pourrait découvrir d’anciens scripts ou un CDN d’analyse marketing qui déclenche des violations répétées. Elles itèrent, ajoutent à la liste d’autorisation les fournisseurs fiables, puis appliquent la stratégie finalisée par étapes afin de minimiser les perturbations.

Passer du mode Report-Only au mode appliqué peut révéler des pièges cachés, en particulier avec les scripts tiers ou le contenu dynamique. 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 acteurs concernés.

Synthèse des principales différences entre les modes Report-Only et appliqué

• Comportement : le mode Report-Only signale uniquement les violations de stratégie, sans bloquer aucun contenu. Le mode appliqué bloque activement tout ce qui enfreint votre stratégie CSP.
• Objectif : le mode Report-Only permet de tester et d’affiner les stratégies sans aucun risque pour les utilisateurs. Le mode appliqué assure la protection réelle et fait de vos règles de sécurité une réalité effective.
• Impact sur les utilisateurs : le mode Report-Only est invisible, les utilisateurs ne le remarquent jamais. Le mode appliqué peut casser 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 convient parfaitement aux déploiements progressifs, à l’analyse des risques et à la vérification de la compatibilité avec les systèmes existants. Le mode appliqué constitue l’étape finale pour atteindre 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.