Générateur CSP
Construisez un en-tête Content-Security-Policy sans apprendre la syntaxe par cœur. Choisissez les sources directive par directive, partez d’un modèle, voyez ce qui est faible et copiez le résultat pour votre serveur, une balise meta ou un fichier _headers. Tout se passe dans votre navigateur.
Construisez votre politique
Partez d’un modèle, cochez les sources dont chaque directive a besoin et ajoutez vos propres hôtes. La politique se met à jour en direct.
La politique est construite dans votre navigateur. Rien de ce que vous choisissez ou collez n’est envoyé à un serveur, journalisé ni enregistré.
Une Content-Security-Policy indique au navigateur exactement d’où une page peut charger scripts, styles, images, polices et cadres. Tout le reste est bloqué, ce qui transforme la plupart des failles XSS en simple erreur de console. Le piège, c’est la syntaxe : un guillemet ou une source oubliés et le site casse. Ce générateur l’écrit pour vous et signale les réglages qui annulent la protection en silence.
Principaux avantages
Cas d’usage courants
Comment l’utiliser
- 1.Choisissez un modèle. Partez de Base stricte, puis ajoutez Google Analytics 4, Google Fonts ou les autres modèles utilisés par votre site. Ou importez votre politique actuelle.
- 2.Ajustez chaque directive. Cochez les mots-clés nécessaires et saisissez des hôtes supplémentaires, comme
https://cdn.exemple.fr, dans la case en dessous. - 3.Lisez le contrôle. Corrigez ce qui est marqué ✗ et tranchez pour ce qui est marqué ⚠. Chaque message explique l’enjeu.
- 4.Déployez d’abord en rapport seul. Activez le mode rapport seul, copiez l’extrait pour votre serveur et surveillez la console du navigateur quelques jours avant d’appliquer.
Les directives qui comptent le plus
Commencez strict avec default-src et n’ouvrez que ce qu’une vraie fonctionnalité exige. Ces six réglages portent l’essentiel de la protection.
'unsafe-inline' ; autorisez le code en ligne avec un nonce ou un hachage, et ne listez que les hôtes de scripts réellement utilisés.Fonctions clés
- 14 directives, chacune avec ses mots-clés et des hôtes libres
- Modèles pour une base stricte, Google Analytics 4, Google Fonts, YouTube et Stripe
- Importe un en-tête existant pour le relire ou le compléter
- Contrôle en direct de unsafe-inline, unsafe-eval, https:, data:, des jokers et des directives manquantes
- Mode rapport seul, upgrade-insecure-requests et report-uri
- Sortie pour en-tête HTTP, balise meta, Nginx, Apache et fichiers _headers
- Tourne dans votre navigateur ; rien n’est envoyé
Une CSP est une seconde ligne de défense
La CSP limite les dégâts quand une faille d’injection passe ; elle ne remplace ni l’échappement des sorties ni la validation des entrées. Une politique qui autorise les scripts 'unsafe-inline', ou n’importe quel hôte HTTPS, rassure mais bloque très peu : les avertissements ci-dessus sont le vrai travail.
Déployez une nouvelle politique en douceur : envoyez-la en Report-Only, corrigez ce qui casse, puis appliquez-la. Une fois en ligne, notre vérificateur d’en-têtes de sécurité confirme que l’en-tête est bien envoyé, avec HSTS et les autres. Le guide des en-têtes de sécurité explique comment CSP s’articule avec eux.
Questions fréquentes
Qu’est-ce qu’une Content-Security-Policy ?⌄
C’est un en-tête de réponse HTTP qui liste d’où une page peut charger scripts, styles, images, polices, cadres et autres ressources. Le navigateur bloque tout le reste. Son rôle principal est d’arrêter le cross-site scripting : même si un attaquant injecte une balise script, le navigateur refuse de l’exécuter.
En-tête ou balise meta ?⌄
Utilisez l’en-tête HTTP dès que possible. La balise meta fonctionne pour la plupart des directives, mais elle ne peut porter ni frame-ancestors, ni report-uri, ni le mode rapport seul, et ne s’applique qu’au contenu situé après elle. C’est une solution de repli pour les hébergements sans en-têtes personnalisés.
Pourquoi 'unsafe-inline' est-il dangereux dans script-src ?⌄
Parce qu’il laisse s’exécuter n’importe quel script en ligne, y compris celui d’un attaquant, ce que CSP est justement censée empêcher. Si vous avez besoin de scripts en ligne, donnez à chacun un nonce qui change à chaque réponse, ou autorisez son hachage SHA-256. 'unsafe-inline' dans style-src est bien moins risqué et souvent toléré.
Une CSP va-t-elle casser mon site ?⌄
Une politique stricte bloque généralement quelque chose la première fois : une balise d’analyse, une police, une vidéo intégrée. C’est pourquoi il faut d’abord l’envoyer en Content-Security-Policy-Report-Only, surveiller la console ou votre point de collecte, ajouter les sources vraiment nécessaires, puis seulement l’appliquer.
Comment vérifier que ma CSP est active ?⌄
Ouvrez la page et regardez les en-têtes de réponse dans les outils de développement, ou passez le domaine dans un vérificateur d’en-têtes de sécurité. Les violations apparaissent dans la console avec la directive et l’URL bloquée, ce qui vous dit exactement quoi ajouter.