--- title: "Générateur de CSP stricte à partir des rapports navigateur" description: "Générez une Content Security Policy stricte à partir des rapports des navigateurs, pas d'un crawl. Écartez le bruit, puis passez du report-only au blocage." url: "https://centralcsp.com/fr/platform/csp-builder/" lang: "fr" --- Générateur de CSP # La CSP la plus stricte que votre site puisse exécuter, construite depuis le trafic réel. Une Content Security Policy stricte est votre meilleure défense contre le cross-site scripting, et l'en-tête le plus difficile à écrire à la main. CentralCSP construit la vôtre à partir de ce que rapportent de vrais navigateurs, pas d'un instantané de votre page d'accueil pris par un crawler. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Scannez votre politique actuelle](https://centralcsp.com/fr/tools/csp-scanner/) - Depuis le trafic réel Pas un instantané de crawler - Un en-tête de réponse Aucun agent, aucun script de page - Collecté dans l'UE France, conservés 90 jours - Report-only d'abord On applique quand c'est propre - Directive par directive Chaque source justifiée Comment fonctionne le générateur de CSP ## Des rapports réels vers une politique que vous pouvez appliquer. Un générateur de CSP transforme les rapports de violation que les navigateurs envoient déjà en une Content Security Policy. Au lieu de charger une page dans un navigateur headless, il agrège ce que le navigateur de chaque visiteur a rapporté sur toutes les pages ouvertes, puis propose une politique directive par directive. Pas de crawl, pas de supposition, pas de liste d'autorisation écrite de mémoire. 1. 01 - Collecter ### De vrais navigateurs rapportent chaque source Déployez la politique en report-only que nous générons pour vous. Elle ne bloque rien, et à partir de là le navigateur de chaque visiteur rapporte chaque script, style et connexion que vos pages chargent réellement. 2. 02 - Construire ### Nous rédigeons la politique, directive par directive CentralCSP transforme ces rapports en Content Security Policy : script-src, style-src, connect-src, img-src, font-src et frame-src, chacune remplie des sources exactes que votre trafic réel justifie et d'aucune autre, avec object-src et base-uri fixées à 'none'. 3. 03 - Déployer ### Déployez la politique que vous avez construite Quand la phase report-only est propre, copiez l'en-tête finalisé et placez-le là où vous définissez déjà vos en-têtes : une configuration nginx ou Apache, un worker en edge sur votre CDN, ou un middleware de framework. Servez-le en mode bloquant et le navigateur bloque tout ce que la politique n'autorise pas. ### Vous approuvez la politique avant qu'elle parte. Chaque source proposée par le générateur porte sa preuve : combien de navigateurs l'ont chargée, sur quelles pages, et quand elle a été vue pour la dernière fois. Une vraie dépendance saute aux yeux, et le déchet injecté par les bloqueurs de publicité et les gestionnaires de mots de passe est signalé comme bruit d'extension pour qu'il n'atterrisse jamais dans votre liste d'autorisation. Gardez ce qui est réel, écartez le reste, une directive à la fois. - Chaque source classée par volume de rapports - Le bruit des extensions signalé pour vous - Gardez ou écartez, directive par directive ### Elle part stricte, pas juste fonctionnelle. Un crawler produit une liste permissive qui, par chance, charge votre page. Une politique fondée sur les rapports verrouille script-src sur les hôtes exacts qu'utilise votre trafic, ferme connect-src aux seules origines auxquelles vous parlez vraiment, et règle object-src et base-uri sur none. Là où un script inline forcerait unsafe-inline, le générateur le signale au lieu d'affaiblir discrètement la politique : un attaquant n'obtient aucun point d'appui XSS depuis une faille que vous n'aviez pas remarquée. - script-src limité aux hôtes que vous chargez réellement - connect-src, object-src et base-uri verrouillés - Les scripts inline signalés, jamais autorisés en silence Approches ## Trois façons d'obtenir une Content Security Policy. Une CSP ne vaut que par sa couverture. Voici la comparaison honnête entre l'écrire à la main, scanner une page pour en obtenir une, et la construire à partir du trafic que vous avez déjà. Comparaison des façons de produire une Content Security Policy | | CentralCSP | Crawler / scanner | À la main | | --- | --- | --- | --- | | Couvre les pages derrière une connexion | Chaque page visitée | Page d'accueil seulement | Si vous y pensez | | Voit les tiers conditionnels | Les sessions réelles les captent | Manqué si non déclenché | Seulement ce que vous connaissez | | Filtre le bruit des extensions | Signalé par le volume | Non distingué | Vous devinez | | Reste à jour quand le site évolue | Les nouveaux rapports montrent les écarts | Un instantané unique | Réécriture manuelle | | Passe en mode strict sans risque | Report-only, puis blocage | Politique de départ seulement | Des jours de tests | Il existe une quatrième voie : injecter localement une politique report-only avec une extension de navigateur et construire à partir de ce que ce seul navigateur voit. C'est réellement efficace pour rédiger et déboguer une page, et [notre extension Chrome fait exactement cela, gratuitement](https://centralcsp.com/fr/tools/extension/). La couverture de tout le site demande malgré tout du trafic réel : un navigateur sur une page, ce n'est pas votre site. Alertes ## Une nouvelle source apparaît ? Vous êtes prévenu. Les rapports qui construisent votre politique peuvent aussi vous alerter. Quand un script se charge depuis une origine que votre politique n'a jamais autorisée, CentralCSP l'envoie dans Slack, Teams, Google Chat, Telegram ou par e-mail avant que le prochain visiteur ne charge la page. - Règles nouvelle origine et changement de hash - Pics de violations après un déploiement - Dirigé vers le canal responsable de la page [Voir les alertes](https://centralcsp.com/fr/platform/alerting/) Surveillance ## La CSP n'est qu'un rapport. Les navigateurs en envoient onze autres. Votre politique ne rapporte que ce qu'elle bloque. De vrais navigateurs rapportent aussi les erreurs réseau, les onglets plantés, les dépréciations et les échecs d'intégrité, et CentralCSP collecte les douze types sur le même endpoint, dédupliqués et classés. - Les 12 types de rapports navigateur, un seul endpoint - Dédupliqués, groupés et cherchables - Les défaillances côté serveur que le navigateur voit en premier [Voir la surveillance](https://centralcsp.com/fr/platform/monitoring/) Vérifiez vos en-têtes ## Qu'envoie votre site aujourd'hui ? Deux minutes, sans compte : scannez vos en-têtes en direct et voyez si vous avez seulement une Content Security Policy, à quel point elle est stricte, et quelles origines peuvent exécuter du code sur vos pages en ce moment. Scanner mon site Gratuit, sans compte. Les résultats arrivent sur une page partageable. [Créez une politique dans votre navigateur avec l'extension](https://centralcsp.com/fr/tools/extension/). Pour aller plus loin ## Comment une politique se construit, en détail Le report-only, l'en-tête d'endpoint, et le déploiement de la politique finale sur votre stack. - [Comment utiliser le CSP Builder](https://centralcsp.com/fr/blog/how-to-use-csp-builder) - [L'en-tête Content-Security-Policy-Report-Only](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/report-only) - [L'en-tête Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) - [Pourquoi unsafe-inline annule votre CSP](https://centralcsp.com/fr/blog/unsafe-inline-csp) - [Lire les rapports de violation CSP](https://centralcsp.com/fr/docs/platform/monitoring/csp) - [Envoyer l'en-tête CSP avec nginx, Next.js et les autres](https://centralcsp.com/fr/blog/set-csp-header-every-framework) FAQ ## Questions fréquentes Construire une politique, filtrer le bruit et la déployer, en réponses. ### Peut-on vraiment construire une Content Security Policy à partir du trafic réel ? Oui, et c'est tout l'intérêt. Vous déployez une fois une politique en report-only, et chaque navigateur qui visite rapporte les scripts, styles et connexions que vos pages chargent. CentralCSP agrège ces rapports en une politique qui couvre tout votre site, y compris les pages et les tiers qu'un crawler d'une seule page n'atteint jamais. ### Une CSP générée va-t-elle casser mon site quand je l'active ? Pas de la façon dont nous la déployons. La politique tourne d'abord en report-only : elle rapporte les violations mais ne bloque rien, vous voyez donc exactement ce que le blocage casserait avant que ça casse. Vous passez en mode bloquant seulement quand la phase report-only est propre, et vous pouvez revenir en arrière à tout moment. ### Qu'est-ce que le mode report-only ? Une Content Security Policy peut être envoyée sous deux formes. Content-Security-Policy applique la règle : le navigateur bloque tout ce que la politique interdit. Content-Security-Policy-Report-Only se contente de rapporter les violations et ne bloque rien. Le report-only est la façon de tester une politique sur du trafic réel sans risque, et c'est là que commence chaque politique ici. ### Combien de temps faut-il collecter avant de bloquer ? Jusqu'à ce que le flux de rapports se stabilise et que vos parcours importants aient été parcourus par du trafic réel. Le paiement, la connexion et l'administration sont ceux qui comptent : une page que personne n'a visitée pendant la phase report-only est une page dont vous n'avez pas encore vu les sources. Les sites à fort trafic se stabilisent en quelques jours ; une page peu visitée peut demander des semaines, et une page de campagne trimestrielle n'apparaîtra qu'au lancement de la campagne. Il n'y a pas d'échéance : le report-only peut rester actif indéfiniment et continue de rapporter pendant tout ce temps. ### Comment filtrez-vous le bruit des extensions de navigateur ? Les bloqueurs de publicité, gestionnaires de mots de passe et autres extensions injectent du code dans chaque page, et ce code déclenche votre politique. C'est la principale raison pour laquelle les rapports CSP semblent noyés dans le bruit. CentralCSP classe chaque source selon le nombre de navigateurs et de pages qui l'ont rapportée et signale le motif d'injection par extension, pour qu'une source apparue une seule fois dans le navigateur d'un utilisateur ne soit pas prise pour une vraie dépendance. ### Que deviennent mes scripts inline ? Ils sont signalés, pas laissés passer. Le générateur n'ajoutera pas 'unsafe-inline' pour faire disparaître un rapport, parce que ce seul mot-clé annule l'essentiel de ce contre quoi une directive script-src vous protège. Un script inline apparaît comme un constat avec deux correctifs honnêtes : le déplacer dans un fichier externe, ce qui est la réponse durable, ou autoriser ce script précis par un hash ou un nonce. Le hash est une empreinte des octets exacts du script : il cesse de fonctionner dès que le contenu change, et c'est justement le but. ### En quoi est-ce différent d'un générateur de CSP gratuit qui scanne mon URL ? Un scanner charge une page dans un navigateur headless et écrit une politique pour ce qu'il a vu par hasard. Il rate tout ce qui se trouve derrière une connexion, un clic ou un test A/B, ainsi que le widget tiers qui ne se charge que pour certains visiteurs. Une politique construite à partir du trafic réel couvre tout cela, parce que les rapports viennent de vrais utilisateurs sur chaque page qu'ils ont réellement ouverte. ### Faut-il déjà avoir une CSP pour commencer ? Non. Vous partez d'une base stricte en report-only (default-src 'none'), vous collectez le temps que votre trafic le nécessite, et vous laissez le générateur remplir les directives à partir de ce que rapportent les vrais navigateurs. Si vous avez déjà une CSP, pointez son report-to vers le même endpoint et CentralCSP s'appuie sur l'existant. ### La politique reste-t-elle à jour quand mon site évolue ? Les rapports continuent d'arriver, donc le générateur continue de montrer les écarts : un nouveau script, une nouvelle origine, une source qui a cessé d'apparaître. Vous resserrez la politique quand quelque chose de légitime est ajouté et vous êtes alerté quand quelque chose que vous n'avez jamais approuvé surgit, au lieu de réécrire l'en-tête à la main à chaque mise en production. ## Commencez à collecter aujourd'hui. Appliquez quand vous êtes prêt. Déployez un seul en-tête report-only cet après-midi et regardez la politique se rédiger toute seule à partir de votre trafic réel. Essai gratuit de 14 jours, sans agent, sans script de page. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Évaluez une politique gratuitement](https://centralcsp.com/fr/tools/csp-evaluator/) --- Disponible en : [en](https://centralcsp.com/en/platform/csp-builder/), [fr](https://centralcsp.com/fr/platform/csp-builder/)