--- title: "Générateur de CSP à partir du trafic réel du navigateur" description: "Construisez une CSP stricte à partir des rapports de vrais navigateurs, pas d'un crawl d'une page. Écartez le bruit, puis passez du report-only au blocage." url: "https://next.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.next.centralcsp.com) [Scannez votre politique actuelle](https://next.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 - Report-only d'abord On applique quand c'est propre - Directive par directive Chaque source justifiée Comment ça marche ## Des rapports réels vers une politique que vous pouvez appliquer. Pas de crawl, pas de suppositions, pas de liste d'autorisation tapée de mémoire. Les navigateurs de vos visiteurs font le travail de terrain, et vous approuvez le résultat. 1. MyEndpoint.report.centralcsp.com 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 une Content Security Policy : script-src, connect-src, style-src et les autres, chacune remplie des sources exactes que votre trafic réel justifie, et de rien d'autre. 3. 03 - Déployer ### Déployez la politique que vous avez construite Une fois la phase report-only propre, copiez l'en-tête finalisé et déployez-le depuis votre CDN, proxy ou 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 | Oui: Chaque page visitée | Non: Page d'accueil seulement | En partie: Si vous y pensez | | Voit les tiers conditionnels | Oui: Les sessions réelles les captent | Non: Manqué si non déclenché | En partie: Seulement ce que vous connaissez | | Filtre le bruit des extensions | Oui: Signalé par le volume | Non: Non distingué | Non: Vous devinez | | Reste à jour quand le site évolue | Oui: Les nouveaux rapports montrent les écarts | Non: Un instantané unique | Non: Réécriture manuelle | | Passe en mode strict sans risque | Oui: Report-only, puis blocage | En partie: Politique de départ seulement | Non: Des jours de tests | 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://next.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://next.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. 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. ### 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. ### 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.next.centralcsp.com) [Évaluez une politique gratuitement](https://next.centralcsp.com/fr/tools/csp-evaluator/) --- Disponible en : [en](https://next.centralcsp.com/en/platform/csp-builder/), [fr](https://next.centralcsp.com/fr/platform/csp-builder/)