Qu'est-ce qu'un générateur d'en-tête CSP ?
La politique de sécurité du contenu (CSP) est une norme de sécurité du navigateur qui permet d'empêcher les scripts intersites (XSS), le détournement de clics et d'autres attaques par injection de code en définissant les sources de contenu autorisées à se charger sur une page Web. Un générateur d'en-tête CSP fournit une interface visuelle pour construire des chaînes d'en-tête CSP valides sans mémoriser la syntaxe des directives. Vous activez ou désactivez les directives, sélectionnez les valeurs sources autorisées telles que 'self', 'unsafe-inline' ou des domaines spécifiques, et l'outil génère la chaîne d'en-tête correcte en temps réel. Il vous avertit également des configurations conflictuelles ou non sécurisées, telles que la combinaison de 'unsafe-inline' avec 'strict-dynamic', ou l'utilisation de 'unsafe-eval' qui réactive l'exécution dangereuse de JavaScript.
Comment utiliser le générateur d'en-tête CSP
- 1Activez les directives dont vous avez besoin en les activant. Commencez par 'default-src' comme stratégie de secours de base.
- 2Pour chaque directive activée, cliquez sur les valeurs source que vous souhaitez autoriser (e.g., 'self', https:, data:). Les valeurs sélectionnées sont surlignées en bleu.
- 3Ajoutez des domaines personnalisés en les saisissant dans le champ de saisie et en appuyant sur Entrée ou en cliquant sur Ajouter (e.g., https://cdn.example.com).
- 4Examinez tous les avertissements jaunes qui apparaissent : ils indiquent des combinaisons de directives contradictoires ou non sécurisées.
- 5Copiez la chaîne d'en-tête CSP générée ou la balise méta HTML à l'aide des boutons de copie.
- 6Vous pouvez éventuellement saisir une URL de test pour vérifier si elle serait autorisée ou bloquée par votre politique actuelle.
Cas d'utilisation courants
Renforcement de la sécurité des applications Web
Créez une politique CSP stricte pour votre site Web de production afin de bloquer les scripts en ligne, de restreindre l'origine des ressources et d'empêcher les attaques XSS. Commencez avec un default-src 'none' restrictif et autorisez sélectivement uniquement les sources dont votre application a besoin.
Migrer progressivement vers CSP
Lorsque vous ajoutez CSP à une application existante, utilisez le générateur pour expérimenter différentes combinaisons de directives, identifiez les sources requises par votre application et resserrez progressivement la politique sans interrompre les fonctionnalités.
Débogage des violations CSP
Lorsque la console de votre navigateur affiche des erreurs de violation CSP, utilisez la fonctionnalité de test d'URL pour vérifier si une URL de ressource spécifique est autorisée par votre politique actuelle et ajustez les directives en conséquence.
Générer des balises méta pour les sites statiques
Pour les sites statiques hébergés sur des plates-formes sur lesquelles vous ne pouvez pas définir d'en-têtes HTTP, copiez la balise méta HTML générée pour intégrer la stratégie CSP directement dans la section d'en-tête de votre document HTML.
Questions fréquentes
Quelle est la différence entre CSP en tant qu'en-tête HTTP et balise méta ?
Les deux méthodes fournissent la même politique au navigateur. L'en-tête HTTP (Content-Security-Policy) est défini par le serveur et prend en charge toutes les directives. La balise méta HTML (meta http-equiv Content-Security-Policy) est intégrée à la page et fonctionne pour la plupart des directives, mais ne prend pas en charge les frame-ancestors, report-uri ou sandbox. L'en-tête HTTP est généralement préféré car il est appliqué avant l'analyse du code HTML de la page.
Que fait 'strict-dynamic' et pourquoi ignore-t-il 'unsafe-inline' ?
'strict-dynamic' indique au navigateur de faire confiance aux scripts chargés par des scripts déjà approuvés (via un nom occasionnel ou un hachage), même à partir de nouvelles origines. Lorsque 'strict-dynamic' est présent, le navigateur ignore 'unsafe-inline' et les listes autorisées basées sur l'hôte pour script-src. Ceci est inhérent à la conception : cela permet une approche basée sur le nonce dans laquelle seuls les scripts explicitement non spécifiés s'exécutent et peuvent charger dynamiquement des scripts supplémentaires.
Dois-je toujours définir default-src ?
Oui, default-src agit comme une solution de secours pour toute directive que vous donnez't explicitly set. If you define script-src but not style-src, the browser uses default-src for styles. Setting default-src to 'none' or 'self' établit une ligne de base sécurisée que vous assouplissez ensuite par directive si nécessaire.
Pourquoi 'unsafe-eval' est-il dangereux ?
'unsafe-eval' permet l'utilisation de eval(), du nouveau Function(), de setTimeout avec des chaînes et d'autres API d'exécution de code dynamique. Il s'agit de vecteurs d'attaque XSS courants, car ils permettent à un attaquant d'exécuter du JavaScript arbitraire s'il peut injecter une chaîne dans votre application. Évitez 'unsafe-eval' sauf si cela est absolument requis par votre framework ou vos bibliothèques.
Cet outil valide-t-il l'en-tête CSP par rapport à la spécification officielle ?
Cet outil génère des en-têtes CSP syntaxiquement corrects et avertit des combinaisons courantes conflictuelles ou non sécurisées. Cependant, il n'effectue pas de validation exhaustive des spécifications du W3C. Pour le déploiement en production, testez votre CSP dans un environnement intermédiaire à l'aide de la console de développement du navigateur pour détecter toute violation.