Analyseur CSP

Analysez Content-Security-Policy (CSP) et Content-Security-Policy-Report-Only pour n'importe quelle URL. Détectez les directives risquées (unsafe-inline, caractères génériques), les stratégies nonce/hachage manquantes, les modèles obsolètes, et obtenez des recommandations actionnables pour renforcer les défenses XSS. Prend en charge les redirections, l'inspection brute des en-têtes, le filtrage, les constatations, et l'export JSON/PDF.

Loading…

À propos Analyseur CSP

Collez une URL pour inspecter ses en-têtes CSP et voir rapidement si la politique vous protège réellement contre le XSS et les injections. Cet analyseur met en évidence les autorisations dangereuses (comme unsafe-inline ou les caractères génériques larges), explique ce qui manque (stratégie nonce/hachage, restrictions de frame), et vous aide à évoluer vers un CSP pratique et déployable en utilisant report-only en toute sécurité.

Fonctionnalités

Détecter et expliquer les en-têtes Content-Security-Policy et Content-Security-Policy-Report-Only.
Signaler les pièges courants du CSP : unsafe-inline, unsafe-eval, caractères génériques larges et sources trop permissives.
Conseils pour une exécution plus sûre des scripts/styles via des stratégies basées sur nonce et hachage.
Identifier les directives manquantes qui comptent souvent dans le renforcement réel (ex. : frame-ancestors, object-src, base-uri).
Insights Report-Only : comprendre ce qui serait bloqué et comment déployer le CSP sans casser la production.
Suivre les redirections (jusqu'à 10) pour analyser la politique finale appliquée par les navigateurs.
Vue brute des en-têtes pour la sortie exacte du serveur et le débogage.
Constatations + fiche de score avec filtrage "problèmes uniquement".
Exporter l'analyse en JSON ou PDF pour les audits, tickets et revues de sécurité.
Inclut la sensibilisation aux en-têtes obsolètes pour détecter les politiques héritées et les besoins de migration.

🧭 Comment utiliser for csp-analyzer

Entrez l'URL à analyser

Collez l'URL de la page que vous souhaitez vérifier (souvent votre page d'accueil ou l'enveloppe de l'application).

Activez le suivi des redirections si nécessaire

Gardez "Suivre les redirections" activé pour que l'analyseur atteigne la destination HTTPS/www/locale finale où le vrai CSP est retourné.

Consultez la fiche de score et les constatations

Commencez par les constatations pour repérer les risques critiques (unsafe-inline, caractères génériques, restrictions manquantes) et comprendre quelles directives influencent le score.

Inspectez les en-têtes bruts lors du débogage

Activez "Afficher les en-têtes bruts" pour vérifier les noms/valeurs exacts des en-têtes (utile si plusieurs en-têtes CSP sont présents ou si un proxy/CDN les modifie).

Exportez un rapport pour votre flux de travail de sécurité

Téléchargez le JSON pour l'automatisation ou le PDF pour les audits de sécurité et les tickets d'ingénierie.

Spécifications techniques

Modèle de requête

Cet outil effectue une inspection des en-têtes d'URL et se concentre sur l'analyse des en-têtes de sécurité, y compris les politiques CSP et report-only.

Paramètre	Comportement	Par défaut
Suivre les redirections	Suit la chaîne de redirections pour analyser la politique effective renvoyée par l'URL finale	Activé
Redirections max	Limite de redirections pour éviter les boucles	10
Délai d'attente	Limite de délai d'attente de la requête	15000 ms
Agent utilisateur	Identifie l'agent utilisateur de la requête	Encode64Bot/1.0 (+https://encode64.com)
Réseaux privés	Bloque l'accès aux plages de réseaux privés pour la sécurité	Désactivé (réseaux privés non autorisés)

En-têtes CSP inspectés

L'analyseur vérifie les politiques d'application et de non-application et les présente sous une forme lisible.

En-tête	Signification
Content-Security-Policy	Politique appliquée et respectée par le navigateur
Content-Security-Policy-Report-Only	Politique non bloquante qui signale les violations (utile pour le déploiement et l'ajustement)

Les sites peuvent émettre plusieurs en-têtes CSP. Les navigateurs appliquent des règles de combinaison/priorité qui peuvent être complexes — les en-têtes bruts aident à confirmer ce qui est envoyé.

Ce que l'analyse recherche

Les résultats sont basés sur des vérifications pratiques de renforcement CSP et des erreurs de déploiement courantes.

Domaine	Exemples de résultats
Robustesse de la politique de script	utilisation de unsafe-inline / unsafe-eval, sources génériques, stratégie nonce/hash manquante
Robustesse de la politique de style	styles unsafe-inline, sources trop larges, chemin de migration vers nonces/hashes manquant lorsque possible
Résistance au framing et au clickjacking	Restrictions de cadre manquantes ou faibles (souvent via frame-ancestors)
Modèles obsolètes / dépréciés	Anciennes directives ou modèles qui devraient être modernisés
Préparation au déploiement	Visibilité des points de terminaison de présence et de signalement en mode Rapport-Seulement

Ligne de commande

Utilisez ces commandes pour inspecter rapidement les en-têtes CSP. Elles sont utiles pour valider ce que l'analyseur rapporte.

macOS / Linux

Récupérer les en-têtes de réponse (rechercher CSP)

curl -I https://example.com

Inspectez Content-Security-Policy et Content-Security-Policy-Report-Only dans les en-têtes de réponse.

Suivre les redirections tout en vérifiant les en-têtes

curl -IL https://example.com

Garantit que vous voyez les en-têtes CSP de la destination finale (HTTPS, www, route de l'app shell).

Afficher uniquement les en-têtes CSP (correspondance insensible à la casse)

curl -I https://example.com | grep -i "content-security-policy"

Isole rapidement les en-têtes CSP et de rapport-seulement de l'ensemble complet des en-têtes.

Windows (PowerShell)

Inspecter les en-têtes CSP

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Affiche les en-têtes CSP d'application et de rapport-seulement s'ils sont présents.

Déployez d'abord les nouvelles politiques en mode Rapport-Seulement, examinez les rapports de violation, puis resserrez et appliquez. L'ajustement du CSP est itératif pour les applications modernes.

Cas d'utilisation

Renforcer un site contre les XSS

Utilisez CSP pour réduire l'impact des vulnérabilités d'injection en restreignant les sources de chargement des scripts/styles et la gestion du code en ligne.

Identifier unsafe-inline/unsafe-eval et planifier une migration vers les nonces/hachages
Restreindre les sources script-src/style-src aux origines de confiance
Ajouter les directives défensives manquantes (base-uri, object-src, frame-ancestors)

Déployer CSP en toute sécurité avec Rapport-Seulement

Introduisez CSP progressivement sans casser la production en commençant par Content-Security-Policy-Report-Only et en itérant sur les violations.

Détecter la présence d'une politique en mode rapport-seulement
Comprendre ce qui serait bloqué avant l'application
Exporter un rapport pour votre plan de déploiement et les tickets

Déboguer des scripts, iframes ou widgets tiers cassés

Un CSP trop strict peut bloquer les analyses, les intégrations ou les connexions API. Utilisez l'analyseur pour voir ce que la politique autorise et où vous pourriez avoir besoin de sources explicites.

Confirmer les sources autorisées pour script/img/connect/frame
Détecter les caractères génériques trop larges ajoutés comme solution rapide
Remplacer les autorisations larges par des domaines ciblés

Revue de sécurité / preuve de conformité

Générez un rapport cohérent de la posture CSP actuelle pour les revues de sécurité, les questionnaires clients ou la conformité interne.

Télécharger le JSON pour suivre les changements dans le temps
Télécharger le PDF pour les artefacts d'audit et le partage

❓ Frequently Asked Questions

❓Qu'est-ce que la CSP et contre quoi protège-t-elle ?

La Politique de Sécurité du Contenu (CSP) est une couche de sécurité appliquée par le navigateur qui restreint les sources de chargement des ressources et l'exécution des scripts/styles. Elle est principalement utilisée pour réduire l'impact des attaques de cross-site scripting (XSS) et d'injection.

❓Quelle est la différence entre CSP et CSP Report-Only ?

Content-Security-Policy est appliquée (elle peut bloquer). Content-Security-Policy-Report-Only ne bloque pas ; elle signale les violations pour que vous puissiez ajuster une politique avant de l'appliquer.

❓Pourquoi unsafe-inline est-il considéré comme dangereux ?

unsafe-inline autorise les scripts/styles en ligne, ce qui affaiblit la capacité de la CSP à bloquer le code injecté. Des approches plus sûres utilisent des nonces ou des hachages pour n'autoriser que des blocs en ligne connus tout en bloquant les injections inattendues.

❓Ai-je besoin de nonces ou de hachages ?

Si votre application utilise des scripts ou styles en ligne, les nonces/hachages sont la méthode moderne pour maintenir l'efficacité de la CSP sans casser les fonctionnalités. Ils autorisent des blocs en ligne spécifiques tout en empêchant les injections arbitraires.

❓Un CDN ou un proxy peut-il modifier mon en-tête CSP ?

Oui. Les couches de périphérie peuvent ajouter, fusionner ou remplacer des en-têtes. Si quelque chose semble incohérent, activez les en-têtes bruts et suivez les redirections pour vérifier les en-têtes de réponse finaux.

❓La CSP remplace-t-elle la correction des bogues XSS ?

Non. La CSP est une mesure de défense en profondeur. Vous avez toujours besoin d'un encodage de sortie approprié, de modèles sécurisés et d'une validation des entrées. La CSP réduit le rayon d'impact si quelque chose passe à travers.

❓Est-il sûr de coller des URL ici ?

L'outil effectue des requêtes côté serveur vers l'URL fournie et bloque les cibles de réseau privé. Évitez de mettre des secrets dans les URL (comme des jetons dans les chaînes de requête) et privilégiez les URL publiques que vous connaissez.

Pro Tips

Best Practice

Commencez avec Content-Security-Policy-Report-Only, collectez les violations, puis resserrez et appliquez. La CSP est itérative pour les applications réelles.

Best Practice

Remplacez unsafe-inline par une stratégie de nonce ou de hachage. Gardez les politiques explicites et minimales.

Best Practice

Ajoutez frame-ancestors pour réduire le risque de clickjacking et évitez de vous fier uniquement aux en-têtes hérités.

Best Practice

Évitez les caractères génériques larges comme solution rapide. Privilégiez les domaines ciblés pour les scripts/images/connect et examinez les besoins des tiers.

CI Tip

Exportez un rapport JSON et suivez les changements de CSP dans l'IC pour détecter les régressions lorsque les en-têtes sont modifiés par des mises à jour du CDN/de l'application.