---
title: "Évaluateur CSP gratuit - vérifiez et notez votre politique"
description: "Collez votre Content-Security-Policy et obtenez une note sur 100 : unsafe-inline, jokers et contournements JSONP signalés, correctifs priorisés."
url: "https://centralcsp.com/fr/tools/csp-evaluator/"
lang: "fr"
---
Outils
# Évaluateur CSP
Collez une Content-Security-Policy et obtenez une évaluation notée : les faiblesses signalées directive par directive, avec des correctifs priorisés.
### Évaluer une politique
Collez une Content-Security-Policy et obtenez une évaluation notée : chaque directive vérifiée, les faiblesses signalées, des correctifs priorisés.
Évaluer la politique
Collez la valeur de la politique, avec ou sans le nom de l'en-tête.
La politique est-elle déjà en ligne sur un site ? [Scanner l'URL avec le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/)
Exemple de résultat
## Voyez une politique notée avant de coller la vôtre
Le genre de politique que la plupart des sites livrent encore, notée et signalée directive par directive. Collez la vôtre ci-dessus pour obtenir le même verdict.
43 / 100
Lacunes CSP critiques
Score CSP global
### Prochaines actions
Remplacer 'unsafe-inline' dans script-src par un nonce ou un hash
Cessez d'autoriser des hôtes aux endpoints JSONP connus
Remplacez l'hôte joker par un nom d'hôte exact ou un nonce
Ajoutez object-src 'none' et base-uri 'none'
Sécurité
Dans quelle mesure le site résiste aux attaques côté client.
31 /100
La configuration présente d'importantes lacunes de sécurité.
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' \*.example-cdn.com https://www.google-analytics.com
style-src
'self' 'unsafe-inline'
img-src
\*
* * *
### Constats et recommandations
Problèmes et recommandations de qualité pour cette Content-Security-Policy.
###
'unsafe-inline' laisse s'exécuter n'importe quel script injecté La directive script-src autorise les scripts inline. Un attaquant capable d'injecter du HTML dans la page peut exécuter du JavaScript arbitraire, soit exactement l'attaque qu'une CSP existe pour empêcher.
Critique Sécurité
Critique Sécurité
Recommandation
Remplacez 'unsafe-inline' par un nonce ou un hash pour chaque script inline que vous livrez réellement. Les navigateurs qui prennent en charge CSP niveau 2 ou 3 ignoreront alors un 'unsafe-inline' conservé en repli.
Impact
Toute injection HTML réussie devient un cross-site scripting complet : vol de session, skimming du formulaire de paiement, prise de contrôle de compte.
###
Un hôte autorisé expose un endpoint JSONP qui contourne la politique www.google-analytics.com sert un endpoint JSONP. Comme l'hôte entier est de confiance, un attaquant peut pointer une balise script vers cet endpoint avec le callback de son choix et exécuter du code avec la politique appliquée.
Élevé Sécurité
Élevé Sécurité
Recommandation
Chargez le snippet d'analytics avec un nonce ou un hash plus 'strict-dynamic' au lieu d'autoriser l'hôte, pour que la confiance s'attache au script que vous livrez plutôt qu'à tout ce que sert l'hôte.
Impact
La politique semble stricte mais reste contournable en pratique : une technique publique connue transforme l'hôte de confiance en voie d'exécution.
Exemple
```
```
###
Un hôte joker fait confiance à chaque fichier de chaque sous-domaine \*.example-cdn.com autorise les scripts depuis n'importe quel sous-domaine du CDN. Vous ne faites pas confiance à votre bundle, vous faites confiance à chaque fichier téléversé par un client et à chaque bucket oublié sous ce joker.
Élevé Sécurité
Élevé Sécurité
Recommandation
Épinglez le nom d'hôte exact depuis lequel vous chargez, ou mieux, passez script-src à un nonce ou un hash plus 'strict-dynamic' et supprimez entièrement la liste d'hôtes.
Impact
N'importe quel fichier contrôlé par un attaquant, n'importe où sous le joker, s'exécute comme s'il s'agissait de votre propre code.
###
Aucun repli object-src ni base-uri La politique ne définit ni object-src ni base-uri. Les plugins se rabattent sur default-src, et sans base-uri une balise injectée peut rediriger chaque URL de script relative de la page.
Moyen Sécurité
Moyen Sécurité
Recommandation
Ajoutez object-src 'none' et base-uri 'none', sauf raison documentée de les autoriser.
Impact
Deux échappatoires bien connues restent ouvertes même après la correction de script-src.
###
img-src \* autorise les images depuis n'importe quelle origine Une source d'images joker est rarement exploitable en soi, mais elle rend la politique plus difficile à relire et peut divulguer des données de visiteurs vers des origines arbitraires via des requêtes d'images.
Faible Qualité
Faible Qualité
Recommandation
Listez les origines d'images que vous utilisez réellement, ou utilisez 'self' plus votre CDN.
Impact
Un problème de maintenabilité et de confidentialité plutôt qu'un risque d'exécution direct ; il fait baisser le score de qualité, pas le score de sécurité.
Guide
## Comprendre votre évaluation CSP
Une Content-Security-Policy n'est jamais plus solide que sa directive la plus faible. L'évaluateur lit la politique comme le ferait un attaquant : il cherche le mot-clé, le joker ou l'hôte autorisé qui transforme votre en-tête en contournement.
### Comparaison avec le CSP Evaluator de Google
[le CSP Evaluator de Google](https://csp-evaluator.withgoogle.com) et le nôtre signalent les mêmes faiblesses fondamentales. Ce qui change, c'est ce que vous récupérez, et ce qui se passe une fois la politique déployée.
Notre évaluateur CSP comparé au CSP Evaluator de Google
| Capacité | CentralCSP | le CSP Evaluator de Google |
| --- | --- | --- |
| Sévérité par constat | Oui | Oui |
| Contrôles des contournements par liste d'autorisation et JSONP | Oui | Oui |
| Note globale sur 100 | Oui | Non |
| Scores de sécurité et de qualité distincts | Oui | Non |
| Constats classés par sévérité, chacun avec une action suivante | Oui | Signale la faiblesse |
| Vue des directives analysées, chaque constat rattaché à sa valeur | Oui | Liste par directive |
| Accepte une valeur de politique Report-Only | Oui | Non distingué |
| Remontée des violations une fois la politique déployée | Oui, via CentralCSP | Non |
### Ce que l'évaluateur vérifie
La politique est analysée directive par directive et chaque valeur de source est vérifiée à l'aune de ce qu'un attaquant pourrait exploiter : mots-clés dangereux, sources trop larges, directives de repli manquantes, et hôtes autorisés qui peuvent être détournés pour exécuter du code que la politique devait bloquer. Chaque classe de faiblesse est expliquée dans la [référence de la directive script-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/script-src).
### Comment lire les scores
Le verdict est fait pour être actionné : chaque faiblesse est rattachée à la directive qui l'a causée, avec le correctif juste à côté. Un mot-clé dangereux ? Signalé. Une source assez large pour être détournée ? Signalée aussi. Visez d'abord le score sécurité, une politique soignée peut rester grande ouverte, et traitez les actions dans l'ordre : elles sont déjà triées selon ce qu'un attaquant utiliserait en premier.
### À quoi ressemble un bon score CSP
Deux axes, un seul à poursuivre. Le score de sécurité mesure la résistance de la politique aux attaques réelles ; le score de qualité mesure la propreté de son écriture. Une politique peut être impeccablement rédigée et laisser la porte ouverte : quand les deux divergent, c'est le score de sécurité qui compte.
Ce que signifie chaque tranche de score
| Score | Ce que cela signifie |
| --- | --- |
| 80 et au-dessus | Une configuration CSP solide. À garder sous surveillance pour qu'elle ne dérive pas. |
| De 50 à 79 | Demande de l'attention. La politique existe mais quelque chose en elle annule une bonne part de la protection. |
| En dessous de 50 | Lacunes critiques. Traitez les premiers constats comme le travail à faire, pas comme un backlog. |
### Trois constats que vous verrez presque à coup sûr
'unsafe-inline' dans script-src arrive en premier. Il autorise l'exécution de n'importe quel script injecté, c'est-à-dire exactement ce que la directive existe pour empêcher. Le correctif est un nonce ou un hash pour le code inline dont vous avez réellement besoin.
Un joker ou une longue liste d'hôtes autorisés arrive en deuxième. Un hôte en joker fait confiance à tous les fichiers de tous les sous-domaines, et une longue liste ne vaut que son maillon le plus faible : un seul hôte exposant un endpoint JSONP suffit à contourner la politique. Le correctif est de raccourcir la liste, ou de passer à un nonce avec strict-dynamic pour que la liste cesse de porter tout le poids.
Une directive object-src ou base-uri manquante arrive en troisième. Aucune des deux ne retombe sur default-src d'une manière qui vous protège : réglez-les donc toutes deux sur 'none', sauf raison précise de faire autrement.
### Vérifier une politique avant sa mise en production
Comme l'évaluateur travaille sur le seul texte de la politique, rien n'a besoin d'être en ligne. Collez la valeur depuis votre configuration nginx, votre middleware ou la pull request d'un collègue et relisez-la avant qu'elle n'atteigne la production. Il lit aussi une valeur Content-Security-Policy-Report-Only, pour noter la politique que vous testez avant de l'appliquer.
Une évaluation propre est la première étape, pas une preuve. Déployez d'abord la politique en mode Report-Only et observez ce que remontent de vrais navigateurs ; la politique qui semble stricte sur le papier est souvent celle qui bloque votre propre script de checkout. Une fois le site en ligne, [scannez l'URL avec le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/) pour confirmer que l'en-tête réellement envoyé par votre serveur correspond à ce que vous avez évalué.
### Pourquoi une politique par liste d'autorisation se fait quand même contourner par JSONP
La plupart des politiques en production sont des listes d'autorisation, et c'est pour cela qu'elles échouent : vous ne faites pas confiance à des hôtes, vous faites confiance à chaque fichier qu'ils hébergent, et un seul endpoint abusable sur un CDN autorisé exécute du code attaquant avec la politique appliquée. [Comment les endpoints JSONP contournent votre CSP](https://centralcsp.com/fr/blog/jsonp-csp-bypass) détaille le contournement étape par étape.
La solution est une CSP stricte : remplacez la liste d'hôtes par un nonce ou un hash plus 'strict-dynamic', pour que la confiance s'attache aux scripts que vous avez marqués plutôt qu'à des origines entières, et fermez les points de repli avec object-src 'none' et base-uri 'none'. Le fonctionnement des nonces et des hashs est détaillé dans le [guide des hashs et nonces CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce). La syntaxe complète se trouve dans la [référence de la directive script-src](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/directives/script-src).
### Quand une notation de sécurité signale votre CSP
Des plateformes de notation comme [SecurityScorecard](https://securityscorecard.com) et [Bitsight](https://www.bitsight.com) notent votre CSP depuis l'extérieur, et un constat du type "Content Security Policy Contains Broad Directives" arrive souvent via un client ou un assureur. Collez ici la politique exacte du constat pour voir ce que leur scanner a vu et quelle directive l'a déclenché.
Corrigez la directive signalée, évaluez la politique corrigée jusqu'à ce qu'elle revienne propre, puis déployez-la et utilisez le flux de résolution ou de rescan de la plateforme. Une politique grande ouverte et décorative n'aide plus : les scanners de notation classent les politiques permissives comme des échecs, donc le constat ne se clôture qu'avec une politique réellement plus stricte.
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)
- [Les rapports de violation CSP](https://centralcsp.com/fr/docs/web-security/reporting-api/reports/csp-violation)
- [Comment les endpoints JSONP contournent une CSP](https://centralcsp.com/fr/blog/jsonp-csp-bypass)
- [strict-dynamic expliqué](https://centralcsp.com/fr/blog/strict-dynamic-csp)
- [Référence des mots-clés CSP](https://centralcsp.com/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
- [Un modèle de CSP stricte à copier](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é.
### Scanner CSP
Récupérez la Content-Security-Policy réellement servie par une URL et notez-la face aux contournements connus, aux sources joker et aux directives manquantes.
- Constats au niveau des directives
- Lien de résultats partageable
[Lancer le scanner CSP](https://centralcsp.com/fr/tools/csp-scanner/)
### 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
Scores, contournements et vérifications avant déploiement : les réponses.
### Cet évaluateur CSP est-il gratuit ?
Oui. Collez une politique et évaluez-la aussi souvent que nécessaire : pas de compte, pas d'e-mail, rien à installer. La politique est analysée par l'API CentralCSP et le verdict revient en quelques secondes ; une vérification anti-bot invisible s'exécute en arrière-plan à la place d'un puzzle captcha. Seul le texte de la politique que vous collez est transmis. Rien d'autre concernant votre site n'est sollicité : aucun crawl, aucune requête vers votre serveur.
### Quelle différence entre l'évaluateur CSP et le scanner CSP ?
L'évaluateur lit une politique que vous collez : il fonctionne donc avant tout déploiement, sur un fichier de configuration, une pull request ou un en-tête copié depuis un guide. Le scanner prend une URL, charge la page et lit la Content-Security-Policy réellement envoyée par le serveur, y compris en Report-Only : c'est ainsi que l'on vérifie ce qui est en ligne plutôt que ce que l'on croyait avoir déployé. Les deux utilisent la même échelle de sévérité et les mêmes tranches de score : un verdict de l'un est directement comparable à l'autre.
### En quoi est-ce différent du CSP Evaluator de Google ?
Le CSP Evaluator de Google signale les faiblesses d'une politique collée, et il le fait bien. Cet outil signale les mêmes problèmes de fond et y ajoute une note de 0 à 100, des scores sécurité et qualité séparés, des actions prioritaires classées par sévérité, et une vue analysée qui rattache chaque constat à la directive qui l'a causé. C'est aussi la porte d'entrée vers la surveillance : une fois la politique déployée, CentralCSP peut collecter les rapports de violation de vrais navigateurs au lieu de vous laisser avec un collage ponctuel.
### À quoi ressemble une bonne Content-Security-Policy ?
Une politique stricte fait confiance à des scripts précis, pas à des hôtes entiers : script-src avec un nonce ou un hash plus 'strict-dynamic', object-src 'none' et base-uri 'none'. Les longues listes d'hôtes autorisés, 'unsafe-inline' et les jokers sont ce que les évaluateurs signalent, car chacun est une voie de contournement documentée. Si votre politique est une liste de CDN, attendez-vous à un score de sécurité bas, même si chaque hôte est un hôte que vous utilisez.
### Pourquoi 'unsafe-inline' est-il signalé comme un problème sérieux ?
'unsafe-inline' autorise l'exécution de tous les scripts inline de la page, y compris celui qu'un attaquant injecte, ce qui annule l'intérêt principal d'une CSP. Remplacez-le par un nonce ou un hash pour le code inline que vous livrez réellement. Une nuance : dans une politique qui contient déjà un nonce ou un hash, les navigateurs qui prennent en charge CSP niveau 2 ou 3 ignorent 'unsafe-inline' ; le conserver uniquement comme repli pour les anciens navigateurs est une pratique acceptée et notée en conséquence.
### Puis-je évaluer une politique qui n'est pas encore déployée ?
Oui, c'est tout l'intérêt de coller plutôt que de scanner. L'évaluateur ne lit que le texte de la politique : une valeur issue d'un fichier de configuration, d'une pull request ou d'un essai en Report-Only fonctionne comme un en-tête en production. Une fois la politique déployée, utilisez le scanner CSP pour confirmer que l'en-tête réellement envoyé par votre serveur, sur chaque réponse, correspond à ce que vous avez évalué.
### Un score élevé signifie-t-il que mon site est protégé contre le XSS ?
Non. Le score note le texte de la politique : il ne peut pas voir si l'en-tête est servi sur chaque page, s'il est appliqué ou en Report-Only, ni ce qui casse dans de vrais navigateurs une fois en production. Une CSP stricte est une solide atténuation du XSS, pas un substitut à la correction des failles d'injection. Traitez un score élevé comme un prérequis, puis vérifiez le déploiement avec un scan et surveillez les rapports de violation en production.
## Votre politique va changer. Re-vérifiez-la automatiquement.
L'évaluateur note un instantané. CentralCSP surveille la politique que votre site sert réellement et collecte les rapports de violation depuis les navigateurs de vos visiteurs : un nouveau script, une directive affaiblie ou une page cassée apparaît comme une alerte plutôt que comme un incident. Ajoutez un en-tête, sans changer le 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-evaluator/), [fr](https://centralcsp.com/fr/tools/csp-evaluator/)