--- title: "Scanner CSP gratuit - analyser la Content-Security-Policy" description: "Scanner CSP gratuit : entrez une URL, voyez la Content-Security-Policy réellement envoyée, notée sur 100, avec un correctif par unsafe-inline ou wildcard." url: "https://centralcsp.com/fr/tools/csp-scanner/" lang: "fr" --- Outils # Scanner CSP Saisissez une URL : nous récupérons sa Content-Security-Policy en direct, la notons de 0 à 100 et listons des correctifs priorisés. ### Analyser une URL Récupérez une URL et inspectez sa Content-Security-Policy. Suivre les redirections Analyser la CSP Politique pas encore déployée ? [Collez-la dans l'évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/) Exemple de résultat ## Ce qu'un scan vous donne Un score sur 100, la politique exactement telle que votre serveur l'envoie, et un correctif attaché à chaque valeur signalée. Lancez le scanner ci-dessus pour voir la vôtre. 59 / 100 La CSP nécessite attention Score CSP global ### Prochaines actions Remplacer 'unsafe-inline' dans script-src par un nonce ou un hash Retirer le schéma https: de script-src et nommer chaque origine Ajouter frame-ancestors 'self' à la politique Sécurité Dans quelle mesure le site résiste aux attaques côté client. 52 /100 La configuration présente des lacunes de sécurité à corriger. Qualité Hygiène seule : coquilles, doublons, valeurs obsolètes. 78 /100 Quelques éléments à nettoyer : valeurs obsolètes, directives en double, options qui ne correspondent plus aux pratiques actuelles. Aucun n'affaiblit le site, ils rendent seulement la configuration plus difficile à maintenir. * * * Les valeurs signalées sont teintées selon la sévérité. Sélectionnez-en une pour voir le problème, l'impact et le correctif à appliquer. content-security-policy[](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) default-src 'self' script-src 'self' 'unsafe-inline' https: cdn.example-shop.com style-src 'self' 'unsafe-inline' img-src \* block-all-mixed-content block-all-mixed-content * * * ### Constats et recommandations Problèmes et recommandations de qualité pour cette Content-Security-Policy. ### script-src autorise 'unsafe-inline' Tous les scripts inline de la page sont autorisés à s'exécuter, y compris celui qu'un attaquant injecte. Ce seul mot-clé annule la protection principale de la politique contre le cross-site scripting. Critique Sécurité Critique Sécurité Recommandation Remplacez 'unsafe-inline' par un nonce ou un hash pour que seul le code inline que vous avez approuvé s'exécute, et ajoutez 'strict-dynamic' pour que les scripts de confiance puissent charger leurs dépendances. Impact Un script inline injecté s'exécute avec un accès complet à la page : cookies de session, champs de formulaire et DOM. La plupart des charges XSS sont des scripts inline, c'est donc la première chose qu'un attaquant tente. Exemple ``` script-src 'self' 'nonce-{random}' 'strict-dynamic'; ``` ### script-src autorise le schéma https: nu La source https: permet à la page de charger des scripts depuis n'importe quelle origine HTTPS d'internet. La liste d'autorisation ne liste plus personne ; elle exige seulement de l'attaquant qu'il utilise TLS. Élevé Sécurité Élevé Sécurité Recommandation Retirez https: de script-src et listez les origines exactes depuis lesquelles vous chargez des scripts, comme cdn.example-shop.com. Impact Un attaquant capable d'injecter une balise script peut la pointer vers n'importe quel serveur sous son contrôle, du moment qu'il sert en HTTPS, et la politique l'autorisera. ### frame-ancestors n'est pas définie Rien ne restreint les sites autorisés à intégrer ces pages dans une iframe. default-src ne couvre pas frame-ancestors, le repli ne s'applique donc pas ici. Moyen Sécurité Moyen Sécurité Recommandation Ajoutez frame-ancestors 'self' (ou 'none' si le site n'est jamais intégré) pour bloquer les superpositions de clickjacking. Impact Une page hostile peut encadrer example-shop.com de façon invisible et amener un utilisateur connecté à cliquer sur des boutons qu'il ne voit pas : l'attaque classique de clickjacking. Exemple ``` frame-ancestors 'self'; ``` ### La directive block-all-mixed-content est dépréciée Les navigateurs bloquent désormais le contenu mixte actif par défaut et la directive a été retirée de la spécification CSP. Elle alourdit chaque réponse sans rien protéger de plus. Faible Qualité Faible Qualité Recommandation Retirez block-all-mixed-content. S'il reste des sous-ressources HTTP héritées, utilisez plutôt upgrade-insecure-requests. Impact Aucun impact de sécurité ; c'est un point d'hygiène de politique qui date la configuration. Vous vous demandez si 59 est un mauvais score ? [Comparez un score aux sites de votre secteur](https://centralcsp.com/fr/tools/compare/). Guide ## Comprendre votre scan CSP Votre Content-Security-Policy indique au navigateur ce qu'une page a le droit de charger et d'exécuter, et qui a le droit de l'intégrer : scripts, styles, iframes, connexions et le reste. Notre scanner récupère votre URL comme le ferait un navigateur ou une plateforme de notation, lit la politique réellement envoyée par votre serveur et évalue la qualité de ce travail. ### Que vérifie notre scanner CSP ? Il lit l'en-tête Content-Security-Policy réellement renvoyé par votre serveur, pas celui de votre fichier de configuration, et évalue ce qu'il trouve à l'aune de la façon dont les navigateurs l'appliquent : - Les mots-clés permissifs qui désactivent la protection, comme 'unsafe-inline', 'unsafe-eval' et 'unsafe-hashes'. - Les jokers, les sources de schéma et les hébergeurs mutualisés assez larges pour tout laisser passer, comme \* ou un https: seul. - Les contournements connus tapis dans les origines que vous autorisez : les endpoints JSONP et les script gadgets qui transforment un hôte approuvé en porte de sortie de votre politique. - Les nonces et les hashs qui ne tiennent pas : un nonce identique d'une réponse à l'autre, des guillemets oubliés, ou des valeurs placées dans une directive qui les ignore. - Les directives absentes qui laissent une porte dérobée ouverte, comme object-src, base-uri et frame-ancestors, et la couverture réelle de default-src sur celles que vous avez omises. - Le poids mort et l'obsolète : les directives retirées de la spécification, les définitions en double, les valeurs inconnues et les séparateurs que les navigateurs ignorent en silence. - La politique appliquée et la politique Report-Only, évaluées séparément, car une politique Report-Only ne bloque rien à elle seule. ### Vérifier soi-même la Content-Security-Policy d'un site Ouvrez les DevTools, allez dans l'onglet Réseau, puis rechargez la page. Sélectionnez la requête du document, la première, dont le nom correspond à l'URL de la page. Lisez ses en-têtes de réponse et cherchez Content-Security-Policy. Vérifiez aussi Content-Security-Policy-Report-Only dans la même liste : un site peut envoyer l'un, l'autre ou les deux, et un en-tête Report-Only seul n'applique rien. Depuis un terminal, une seule ligne fait le même travail sans ouvrir de navigateur : Ce que notre scanner ajoute, c'est le jugement : un score sur 100, des constats classés par sévérité avec le correctif à côté de chacun, et les politiques appliquée et Report-Only évaluées séparément plutôt que confondues. ``` curl -sI https://example.com | grep -i content-security-policy ``` ### Pourquoi une politique faible compte Un seul script injecté suffit : des sessions volées, ou un skimmer de cartes installé sur votre paiement pendant des mois. Une Content-Security-Policy est le contrôle côté navigateur qui empêche ce script de s'exécuter, et la majorité du web n'en a pas. Sur les 761 345 sites que nous avons analysés, seuls 19 % servent une CSP, et quand une politique définit script-src, cette directive échoue à nos contrôles de sécurité 89 % du temps. Servir une politique, n'importe laquelle, vous place déjà devant ; en servir une stricte vous place dans une petite minorité. Les chiffres complets sont dans le [rapport State of the Web 2026](https://centralcsp.com/fr/state-of-the-web/). ### Comment fonctionne le scan Saisissez une URL, recevez un rapport noté quelques secondes plus tard : un lien partageable, un bouton de rescan pour vérifier le correctif que vous venez de déployer, et des exports CSV ou PDF pour le ticket ou la piste d'audit. Gratuit, sans compte, et seul est lu ce que votre site répond publiquement, la même chose que reçoit le navigateur de chaque visiteur. ### Scanner, évaluateur ou audit complet des en-têtes ? Le scanner CSP, l'évaluateur CSP et le scanner d'en-têtes comparés | | Scanner CSP | Évaluateur CSP | Scanner d'en-têtes de sécurité | | --- | --- | --- | --- | | Ce que vous lui donnez | Une URL en ligne | Une politique collée | Une URL en ligne | | Ce qu'il note | La politique envoyée par votre serveur | Une politique en brouillon ou de préproduction | Tous les en-têtes de sécurité, avec l'analyse CSP incluse | | Idéal pour | Auditer un site que vous ou un prestataire exploitez | Relire une politique avant déploiement | Une note unique pour tout l'ensemble d'en-têtes | Utilisez notre scanner quand la politique est en ligne : il teste ce que votre serveur envoie réellement, c'est-à-dire ce que voient aussi les navigateurs et les plateformes de notation. Pour un brouillon, une politique de préproduction ou la proposition d'un collègue, collez-la dans l' [Évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/) et obtenez la même analyse notée sans URL publique. Et quand vous voulez toute la posture en un seul passage, HSTS, X-Content-Type-Options, Permissions-Policy, cookies et le reste, lancez le [scanner d'en-têtes de sécurité](https://centralcsp.com/fr/tools/security-headers/) à la place : il note l'ensemble des en-têtes et inclut l'analyse CSP comme l'un de ses volets. Pour aller plus loin - [Présentation de Content-Security-Policy](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy) - [La directive script-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/script-src) - [Hashs et nonces CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) - [L'en-tête Reporting-Endpoints](https://centralcsp.com/fr/docs/web-security/reporting-api/headers/reporting-endpoints) - [Un modèle de CSP stricte à copier puis durcir](https://centralcsp.com/fr/blog/csp-starter-template) Plus d'outils gratuits ## Poursuivez l'audit avec les autres outils gratuits Chaque outil est gratuit, fonctionne sans compte et note avec la même échelle de sévérité. ### Évaluateur CSP Collez une politique pas encore déployée et obtenez la même notation et les mêmes constats qu'un scan en ligne, sans URL. - Auditez avant de déployer - Même moteur de notation [Évaluer une politique dans l'évaluateur CSP](https://centralcsp.com/fr/tools/csp-evaluator/) ### Scanner d'en-têtes de sécurité Notez chaque en-tête de sécurité envoyé par une URL, de HSTS à Permissions-Policy, avec chaque constat expliqué et priorisé. - Tous les en-têtes, une seule note - Correctifs classés par impact [Scanner vos en-têtes de sécurité](https://centralcsp.com/fr/tools/security-headers/) ### Vérificateur Reporting API Vérifiez que le signalement des violations fonctionne vraiment : les endpoints, Reporting-Endpoints et Report-To, et quelles fonctionnalités de sécurité rapportent réellement. - Cartographie des endpoints et fonctionnalités - Pertes silencieuses signalées [Vérifier votre configuration Reporting API](https://centralcsp.com/fr/tools/reporting-api/) ### Générateur de hash SRI Transformez l'URL d'un script ou d'un CSS servi par un CDN en hash Subresource Integrity, avec une balise prête à coller et une vérification CORS. - SHA-256, 384 et 512 - CORS vérifié pour vous [Générer un hash SRI](https://centralcsp.com/fr/tools/sri-hash/) ### Générateur de hash CSP Transformez un script ou un style inline en hash qui l'autorise sous une politique stricte, directement dans votre navigateur. - Fonctionne entièrement côté client - SHA-256, 384 et 512 [Générer un hash CSP](https://centralcsp.com/fr/tools/csp-hash/) ### Comparateur de sites Situez votre score : votre site à côté de la moyenne du jeu de données et des sites les mieux configurés de l'année, contrôle par contrôle. - Références publiées et vérifiables - Vue radar par catégorie [Comparez votre site aux meilleurs](https://centralcsp.com/fr/tools/compare/) FAQ ## Questions fréquentes Vérifier, noter et corriger une Content-Security-Policy : les réponses. ### Comment vérifier si un site a une Content Security Policy ? Deux méthodes. Ouvrez les outils de développement du navigateur, chargez la page et cherchez une ligne content-security-policy dans les en-têtes de réponse de l'onglet Réseau. Ou collez l'URL dans ce scanner : il récupère la page pour vous, affiche la politique trouvée, y compris en mode Report-Only, et lui attribue un score, ce que les outils de développement ne font pas. ### Pourquoi le scanner indique-t-il qu'aucune politique n'a été trouvée ? Trois causes couvrent presque tous les cas. L'en-tête est défini sur certaines routes mais pas sur celle que vous avez scannée, ce qui est fréquent quand la politique est ajoutée dans un middleware de framework qui ne s'exécute pas partout. L'URL a redirigé, et ce qui a été évalué est la réponse finale plutôt que l'adresse saisie : scannez avec et sans redirections, puis comparez. Ou la politique est livrée dans une balise meta http-equiv dans le HTML plutôt que comme en-tête HTTP, ce que le navigateur respecte pour la plupart des directives mais qui n'est pas un en-tête de réponse et ne peut porter ni frame-ancestors, ni report-uri, ni sandbox. ### Pourquoi 'unsafe-inline' est-il signalé comme un problème ? 'unsafe-inline' dans script-src autorise l'exécution de tous les scripts inline de la page, y compris celui qu'un attaquant injecte, soit exactement ce qu'une CSP est censée empêcher. La plupart des charges utiles XSS sont des scripts inline : ce mot-clé annule donc la protection principale de la politique. Remplacez-le par un nonce ou un hash pour que seul le code inline que vous avez approuvé s'exécute. ### Un en-tête Content-Security-Policy-Report-Only suffit-il ? Non. Le mode Report-Only envoie des rapports de violation mais ne bloque rien : à lui seul, il ne protège pas vos utilisateurs. C'est en revanche la bonne première étape : exécutez la politique en Report-Only, corrigez ce qu'elle aurait cassé, puis passez-la dans l'en-tête Content-Security-Policy appliqué. Le scanner affiche les deux en-têtes séparément, pour voir précisément dans quel mode un site se trouve. ### Pourquoi ma notation de sécurité dit-elle que la CSP est absente alors que j'en ai une ? En général parce que la plateforme a observé une réponse différente de celle que vous avez testée. Leurs scanners peuvent évaluer l'URL finale d'une chaîne de redirections, signaler des sous-domaines découverts dans votre empreinte, ou tomber sur des réponses qui omettent l'en-tête. Scannez l'URL exacte citée dans le constat, avec puis sans suivi des redirections, et comparez. Si votre correctif est en ligne, utilisez le flux de résolution ou de re-scan de la plateforme pour que sa prochaine observation enregistre la nouvelle réponse. ### Qu'est-ce qu'un bon score CSP ? Sur ce scanner, 80 et plus indique une configuration solide, 50 à 79 une politique à retravailler, et moins de 50 des lacunes critiques. L'axe sécurité est celui qui compte : il mesure la résistance aux attaques réelles, tandis que l'axe qualité mesure la propreté de la définition. Une politique stricte obtient un bon score sur les deux en autorisant les scripts par nonce ou hash et en verrouillant object-src, base-uri et frame-ancestors. ### En quoi est-ce différent du CSP Evaluator de Google ? L'outil de Google évalue une politique que vous y collez. Ce scanner prend une URL et charge la page lui-même : ce qu'il évalue est donc l'en-tête réellement renvoyé par votre serveur, celui que voient aussi les navigateurs et les plateformes de notation. Il évalue séparément les en-têtes bloquant et Report-Only, classe les constats par sévérité avec un correctif et un exemple d'en-tête pour chacun, et fournit un lien de résultats partageable ainsi qu'un export CSV ou PDF. Pour vérifier une politique pas encore déployée, collez-la plutôt dans notre évaluateur CSP. ### Ce scanner CSP est-il gratuit ? Oui. Pas de compte, pas d'e-mail, pas de quota perceptible en usage normal. Vous pouvez partager le lien des résultats, relancer un scan après un déploiement et exporter les constats en CSV ou en PDF. Le scan lit uniquement la réponse publique de votre site, ce que reçoit le navigateur de n'importe quel visiteur. ## Un scan est un instantané. Votre CSP bouge. Chaque déploiement, changement de tag manager ou mise à jour d'un prestataire peut affaiblir la politique que vous venez de corriger. CentralCSP surveille votre Content-Security-Policy depuis les navigateurs de vos vrais visiteurs et vous prévient dès que quelque chose casse ou qu'un nouveau script apparaît. Ajoutez un en-tête, aucun changement de code. [Commencer avec CentralCSP](https://app.centralcsp.com) [Construire une CSP depuis votre trafic réel](https://centralcsp.com/fr/platform/csp-builder/) --- Disponible en : [en](https://centralcsp.com/en/tools/csp-scanner/), [fr](https://centralcsp.com/fr/tools/csp-scanner/)