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.
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.
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'
Dans quelle mesure le site résiste aux attaques côté client.
La configuration présente d'importantes lacunes de sécurité.
Hygiène seule : coquilles, doublons, valeurs obsolètes.
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.
Constats et recommandations
Problèmes et recommandations de qualité pour cette Content-Security-Policy.
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 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.
| 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.
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.
| 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 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 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. La syntaxe complète se trouve dans la référence de la directive script-src.
Quand une notation de sécurité signale votre CSP
Des plateformes de notation comme SecurityScorecard et Bitsight 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.
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
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
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
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é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
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
FAQ
Questions fréquentes
Scores, contournements et vérifications avant déploiement : les réponses.
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.
