# Extension Chrome CentralCSP (/fr/blog/centralcsp-chrome-extension) Une politique de sécurité du contenu (CSP) est le genre de header que vous ne réglez correctement qu'en observant un vrai navigateur y répondre. Les logs serveur, les environnements de préproduction et les crawlers passent tous à côté de quelque chose. L'extension Chrome CentralCSP transforme votre navigateur en atelier CSP, pour concevoir, déboguer et déployer une politique face à des pages de production sans le moindre déploiement. Cet article détaille ce que fait l'extension, quand recourir à chaque mode, et comment une session passe de l'installation à un header que vous pouvez copier. ## Ce que fait l'extension [#ce-que-fait-lextension] L'extension Chrome CentralCSP est un atelier gratuit côté navigateur pour le travail sur la CSP. Elle fait quatre choses : * Elle diffuse dans un panneau en direct chaque rapport de violation CSP que le navigateur déclenche. * Elle réécrit à la volée le header [`Content-Security-Policy`](/fr/docs/web-security/policies/content-security-policy) que voit votre navigateur, avec une politique que vous fournissez. * Elle assemble une politique fonctionnelle à partir d'une base stricte en report-only au fil de votre navigation sur le site. * Elle s'exécute entièrement sur votre machine. Pas de compte, pas de télémétrie, aucun appel sortant décrivant ce que vous consultez. Elle s'installe dans n'importe quel [navigateur basé sur Chromium](https://developer.chrome.com/docs/extensions). Une fois installée, elle se place à côté des DevTools et reste inactive jusqu'à ce que vous l'activiez pour un site précis. ## Les quatre modes [#les-quatre-modes] Un seul contrôle dans la barre d'outils bascule entre quatre modes. Chacun est une façon différente de se rapporter au header CSP présent sur la page en cet instant. ### Off [#off] L'extension est au repos et les headers du site sont intacts. C'est le comportement par défaut pour tout site sur lequel vous ne l'avez pas explicitement activée. ### Observe [#observe] La politique propre au site continue d'être appliquée. L'extension collecte chaque violation qu'elle produit et les fait remonter dans le panneau. Le mode Observe est le moyen le plus rapide de cartographier ce que votre header actuel casse déjà, ligne par ligne, sans rien changer. Recourez à Observe quand : * Vous avez hérité d'une politique et voulez savoir ce qu'elle fait réellement. * Un fournisseur a été ajouté récemment et vous voulez voir si quelque chose de nouveau se déclenche. * Vous soupçonnez la politique d'être trop restrictive mais ne voulez pas encore risquer de l'assouplir. ### Rewrite [#rewrite] Votre politique candidate remplace le header en direct, ou s'y ajoute. La page répond désormais à vos règles. Les violations se diffusent dans le panneau avec tous les détails : le document URI, le fichier source, la ligne et la colonne pour les blocs inline, et le JSON brut de la violation. Le mode Rewrite prend en charge deux stratégies pour se rapporter au header existant : * Replace, où le header du site est entièrement écrasé par le vôtre. * Append, où vos directives s'ajoutent par-dessus la politique existante du site. Il prend aussi en charge les deux modes d'application que la CSP définit : enforce, où les ressources en violation sont bloquées, et report-only, où les violations sont signalées mais les ressources se chargent quand même. Le mode report-only correspond au header [`Content-Security-Policy-Report-Only`](/fr/docs/web-security/policies/content-security-policy/report-only). ### Build [#build] Le mode Build part d'une base report-only quasiment vide. Au fil de vos clics dans le site, chaque violation est capturée, classée par directive, et intégrée à un header candidat. Une fois que vous avez parcouru les chemins critiques, vous disposez d'une politique ancrée dans ce que la page charge réellement. Recourez à Build quand : * Vous rédigez une politique pour un site qui n'en a pas encore. * Vous repartez de zéro après une refonte majeure. * Vous voulez un instantané de « ce dont cette page a réellement besoin » que vous pourrez affiner en une politique stricte. Le résultat du mode Build est un point de départ, pas un artefact fini. Il capture tout ce que le navigateur a chargé pendant votre navigation, ce qui peut inclure de l'outillage de dev, d'autres extensions de navigateur, ou un pixel marketing déclenché une seule fois. Passez en revue la politique assemblée ligne par ligne avant de la déployer. ## Une session type [#une-session-type] Toute la boucle de rétroaction se déroule dans le navigateur. Il n'y a pas d'environnement de préproduction où déployer et aucun changement serveur tant que vous ne décidez pas de déployer le header. ### 1. Installer [#1-installer] Installez l'extension, elle se loge à côté des DevTools. Elle reste inactive jusqu'à ce que vous l'activiez pour un site. ### 2. Choisir un mode [#2-choisir-un-mode] Le bouton de la barre d'outils bascule entre Off, Observe, Rewrite et Build. Choisissez celui qui correspond à votre objectif. Cartographier les violations actuelles se fait en Observe, tester une politique candidate en Rewrite, et rédiger de zéro en Build. ### 3. Itérer [#3-itérer] Ouvrez le panneau des DevTools, éditez la politique dans l'éditeur, et rafraîchissez la page. Chaque rechargement est une courte boucle de rétroaction face aux vraies tierces parties d'une vraie page. Le panneau montre un graphique des taux de violation par directive sur la dernière minute, un flux de rapports en direct avec l'horodatage, la directive, la source bloquée et la disposition, une vue analysée de la violation la plus récente avec le JSON brut prêt à copier, et la politique actuelle prête à copier sur une seule ligne. ### 4. Relire et déployer [#4-relire-et-déployer] Quand la politique semble bonne, ne la collez pas encore en production. Parcourez-la ligne par ligne et resserrez deux choses. D'abord, resserrez [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src). Remplacez [`'unsafe-inline'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) par un nonce par requête ou [`'strict-dynamic'`](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) partout où c'est possible. Pour un motif courant avec un framework, voyez [comment configurer un nonce CSP avec Next.js](/fr/blog/csp-nonce-nextjs). La différence ressemble à ceci : ```http Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'none' ``` Ensuite, réduisez la liste des hôtes. Retirez tout ce qui venait d'une extension de navigateur, d'outillage de dev, ou d'un pixel marketing ponctuel. La production ne devrait voir que ce dont la production a besoin. Pour approfondir ce nettoyage, voyez [pourquoi `'unsafe-inline'` affaiblit une CSP](/fr/blog/unsafe-inline-csp) et [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp). Déployez d'abord la politique relue en `Content-Security-Policy-Report-Only` pendant un cycle de release. Surveillez les rapports. Quand le flux reste silencieux, promouvez-la vers le header `Content-Security-Policy` appliqué. ## Continuez à collecter des rapports en production [#continuez-à-collecter-des-rapports-en-production] L'extension vous donne une boucle locale rapide. Pour continuer à surveiller les violations après le déploiement, pointez un endpoint de reporting vers CentralCSP et laissez les navigateurs de production envoyer leurs rapports en continu. ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m' 'strict-dynamic'; report-to csp-endpoint ``` La directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) nomme le groupe d'endpoints auquel le navigateur poste les violations. Pour la configuration complète, voyez [démarrer avec le reporting CSP](/fr/blog/get-started-csp-reporting). ## Confidentialité [#confidentialité] Tout reste local. Il n'y a pas de compte ni de télémétrie, et l'extension ne fait aucun appel sortant décrivant les sites que vous consultez. Elle ne lit ou ne modifie le trafic que sur les sites pour lesquels vous l'activez explicitement. Le seul appel réseau qu'elle peut faire est l'endpoint de reporting optionnel que vous configurez dans la politique que vous testez, et uniquement quand des violations se déclenchent alors que le mode Rewrite ou Build est actif. Cet endpoint peut être CentralCSP, votre propre serveur, ou un récepteur de test local. ## Où aller ensuite [#où-aller-ensuite] L'extension couvre la boucle construire-et-déboguer. Quand vous voulez faire évaluer une politique face aux bonnes pratiques sans écrire de code, l'[évaluateur CSP](/tools/csp-evaluator) note une politique collée et signale les directives faibles. À partir de là, la [plateforme CentralCSP](/platform/csp-builder) vous donne la collecte continue des rapports, l'alerting, et un inventaire de scripts sur chaque page en production. ## Articles liés [#articles-liés] * [Comment utiliser le CSP Builder](/fr/blog/how-to-use-csp-builder) * [Comment construire une CSP solide, étape par étape](/fr/blog/how-to-build-a-strong-csp)