Analyseur CSP

Analyse approfondie de la Content Security Policy — décode toutes les directives, détecte unsafe-inline/unsafe-eval, identifie les origines de suivi autorisées dans script-src, et note la force de la CSP de A à F avec un angle de confidentialité.

Comment utiliser Analyseur CSP

  1. 1Entrez l'URL du site Web que vous souhaitez analyser.
  2. 2Consultez chaque directive CSP décodée avec une analyse de sécurité par directive.
  3. 3Examinez les origines de suivi autorisées dans votre script-src (angle de confidentialité).
  4. 4Utilisez les recommandations pour renforcer votre politique.
ZenovayAnalytics

Voyez qui est sur votre site en ce moment.

  • Suivi des visiteurs en temps réel
  • Vie privée d'abord, sans bandeau cookies
  • Installé en deux minutes
Découvrir Zenovay

Questions fréquemment posées

Qu'est-ce que la Content Security Policy (CSP) ?
La Content Security Policy est un en-tête de réponse HTTP qui indique aux navigateurs quelles sources sont autorisées à charger des scripts, des styles, des images et d'autres ressources sur votre page. C'est la principale défense contre les attaques Cross-Site Scripting (XSS) — une CSP correctement configurée empêche l'exécution des scripts injectés même si un attaquant trouve une vulnérabilité XSS.
Pourquoi 'unsafe-inline' dans script-src pose-t-il problème ?
'unsafe-inline' autorise le JavaScript inline (scripts dans des balises <script>, attributs onclick, URL javascript:). C'est le vecteur XSS le plus courant — cela signifie que tout script inline injecté peut s'exécuter. L'utilisation de nonces (jetons cryptographiques à usage unique générés par requête) ou de hashes (SHA-256 des scripts autorisés) permet d'autoriser des scripts inline spécifiques sans activer tous les scripts inline.
Quel est l'angle confidentialité de la CSP ?
Vos directives script-src et connect-src sont essentiellement une liste de permissions de qui peut exécuter du code et recevoir des données depuis votre page. Si vous avez mis Google Analytics, Facebook, TikTok et LinkedIn en liste blanche dans votre CSP, vous autorisez explicitement ces entreprises à exécuter du code sur vos pages et potentiellement à exfiltrer des données utilisateur.
Contre quoi 'object-src: none' protège-t-il ?
object-src contrôle les éléments <object>, <embed> et <applet> — historiquement utilisés pour charger Flash, Java et d'autres plugins. Définir object-src: 'none' empêche tout contenu de plugin de se charger, éliminant toute une classe d'attaques. Cela doit toujours être défini sur 'none' sur les sites modernes.
Quelle est la différence entre CSP et CSP-Report-Only ?
Content-Security-Policy applique la politique — les navigateurs bloquent les violations. Content-Security-Policy-Report-Only ne fait que journaliser les violations vers un point de terminaison de rapport sans rien bloquer. Report-Only est utile pour tester une nouvelle CSP avant de l'appliquer, mais ne fournit aucune protection réelle.
En quoi cet analyseur CSP diffère-t-il des autres outils ?
La plupart des outils CSP ne vérifient que unsafe-inline et les directives manquantes. Cet analyseur recoupe en plus vos script-src et connect-src avec une base de données de plus de 35 domaines de traqueurs et de publicité connus, vous montrant exactement quels courtiers en données et réseaux publicitaires ont une autorisation CSP explicite pour s'exécuter sur votre site.
Qu'est-ce que la directive base-uri et pourquoi est-elle importante ?
base-uri contrôle quelles URL peuvent être utilisées dans l'élément HTML <base>. Si un site est vulnérable à l'injection HTML (mais pas à l'injection de script), un attaquant peut injecter <base href="https://attaquant.com/"> pour rediriger toutes les URL relatives vers son serveur. Définir base-uri: 'none' ou base-uri: 'self' élimine ce vecteur d'attaque.