Générateur CSP — Content Security Policy, avec signalement des pièges
Générateur CSP
Cochez les directives et les sources, et cette page assemble une Content-Security-Policy correcte sur une seule ligne, pour l’en-tête de votre réponse ou la balise <meta> — accompagnée des notes qui comptent : les directives qui ne reviennent jamais à default-src, les cas où un hachage ou un nonce remplace silencieusement unsafe-inline, et ce que strict-dynamic désactive. Un générateur d’empreintes SHA-256/384/512 intégré transforme les scripts et styles en ligne en sources 'sha256-…'. Tout s’exécute dans votre navigateur ; rien n’est envoyé.
Directives de chargement — d’où le contenu peut provenir
Les directives non cochées sont simplement absentes de la politique ; une case cochée sans source sélectionnée est ignorée. 'none' annule les autres cases de sa ligne. La zone sources supplémentaires accepte une liste séparée par des virgules : noms d’hôtes (cdn.example.com), schémas (https:), empreintes et nonces, avec ou sans leurs guillemets.
directive
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
sources supplémentaires
Directives de document — ce que la page elle-même peut faire
Ces quatre-là ne reviennent pas à default-src : les omettre signifie « aucune restriction », si bien qu’une politique complète doit les définir explicitement.
directive
'self'
'none'
sources supplémentaires
Options, nonce et signalement
nonce de script
report-uri
report-to
Politique
Rien n’est encore généré. Cochez quelques sources et appuyez sur Générer la politique, ou chargez l’exemple de référence OWASP.
Générateur d’empreintes pour les scripts et styles en ligne
Collez le contenu exact compris entre <script> et </script> (ou le bloc style) — octet pour octet, sans saut de ligne initial ni final — puis choisissez un algorithme. Le résultat est la source 'sha256-…' attendue par CSP 3.
Le résultat du hachage apparaît ici.
Déployez en en-tête plutôt qu’en balise meta, chaque fois que possible. L’en-tête de réponse est la CSP complète : frame-ancestors, report-uri et report-to ne fonctionnent que là, et un en-tête est appliqué avant même que le premier octet du HTML soit analysé. La balise meta est la solution de repli pour les fichiers statiques sans configuration serveur. Vérifiez les en-têtes réellement envoyés par votre site avec le vérificateur d’en-têtes de sécurité, et décomposez les blocs de réponse bruts avec l’analyseur d’en-têtes HTTP.
Autotest Relance le générateur sur des états fixes : ordre des sources, exclusion mutuelle de 'none', chaîne de référence OWASP, guillemets des nonces et des empreintes, notes d’absence de repli pour base-uri / form-action / frame-ancestors, unsafe-inline neutralisé par un nonce ou un hachage, notes de strict-dynamic, noms d’en-têtes Report-Only, exclusions de la balise meta, générateur d’empreintes comparé à des vecteurs SHA calculés indépendamment, et chemins négatifs. Rien n’est envoyé nulle part.
Qu’est-ce qu’une Content Security Policy ?
En une phrase : une CSP est une liste blanche envoyée par le serveur avec la page, qui indique au navigateur exactement d’où les scripts, styles, images et connexions peuvent provenir — ainsi, même si un attaquant injecte du HTML, le script injecté ne se charge pas, car sa source ne figure pas sur la liste.
oui — une directive non cochée hérite de default-src
Directives de document
base-uri, form-action, frame-ancestors, sandbox
ce que la page elle-même peut faire (être intégrée, envoyer des formulaires, résoudre des URL relatives)
non — chacune doit être définie explicitement
Signalement et divers
report-uri, report-to, upgrade-insecure-requests
où vont les rapports de violation, et la mise à niveau des URL anciennes
non (ce ne sont pas des directives de chargement)
Les pièges les plus subtils, un paragraphe chacun
'unsafe-inline' contre hachages et nonces. Si une directive contient un nonce ou une source de hachage, CSP 3 indique que 'unsafe-inline' est ignoré — il ne reste que pour les navigateurs très anciens. C’est pourquoi « nous avons ajouté un nonce et gardé unsafe-inline par prudence » signifie en réalité que les navigateurs modernes appliquent le nonce. Le générateur signale cette combinaison pour qu’elle relève d’un choix délibéré et non d’un accident.
strict-dynamic désactive votre liste d’autorisations. Avec strict-dynamic dans script-src, les sources d’hôte, les schémas, 'self', 'unsafe-inline' et data: sont tous ignorés pour les scripts ; seuls comptent les nonces et les hachages, et les scripts qu’ils chargent peuvent eux-mêmes charger d’autres scripts. C’est la méthode moderne pour exécuter des scripts de chargement — mais elle rend le reste de la liste script-src purement décoratif.
Les balises meta sont de seconde classe.frame-ancestors, report-uri et report-to sont ignorés dans <meta http-equiv>. Le générateur indique quelles parties de votre politique ne s’appliqueraient pas silencieusement.
Erreurs courantes
Commencer par default-src * plus une longue liste d’exceptions. Procédez dans l’autre sens : un default-src 'self' strict, puis n’élargissez que les directives qui en ont besoin. Les politiques restrictives échouent bruyamment pendant les tests ; les politiques larges échouent silencieusement pour toujours.
Déployer script-src 'unsafe-inline' 'unsafe-eval' et considérer le travail comme terminé. Cette politique ne bloque presque rien de ce qu’une attaque XSS cherche à faire. Mettez un nonce ou un hachage sur vos scripts, ajoutez strict-dynamic, et gardez report-only actif en production pour détecter les régressions.
Oublier que default-src ne couvre pas tout.base-uri, form-action, frame-ancestors et sandbox n’ont aucun repli — la lacune la plus citée dans les déploiements réels de CSP.
Tester d’abord en mode application. Exécutez en Report-Only avec un collecteur pendant une semaine, lisez les rapports, puis passez à l’application. Une politique qui casse le paiement est pire que pas de politique du tout.
Hacher les espaces différemment. Un hachage couvre les octets exacts du bloc en ligne ; une étape de build « utile » qui supprime les sauts de ligne finaux modifie chaque hachage. Générez les empreintes à partir de ce qui est livré, et non à partir du source.
FAQ
Ai-je besoin de default-src si je liste chaque directive ? Non, mais le conserver comme plancher est une bonne pratique : les nouvelles directives de chargement des navigateurs à venir reviendront alors à votre base de référence au lieu d’être « autorisées ».
Que fait réellement upgrade-insecure-requests ? Il demande au navigateur de réécrire chaque URL http:// que la page chargerait — images, styles, requêtes — en https:// avant de la demander. C’est un outil de migration ; l’état final est une page sans aucune URL http://.
Nonce ou hachage ? Un nonce lorsque vous contrôlez la réponse du serveur (une valeur aléatoire par réponse, dans l’en-tête comme dans chaque balise script). Un hachage lorsque le HTML est statique ou mis en cache. Jamais de nonce statique — un nonce qui ne change pas n’est qu’un unsafe-inline avec des étapes en plus.
Pourquoi ma politique est-elle livrée sans que les violations n’arrivent ? Vérifiez si vous êtes en Report-Only (rapports seulement), si report-uri pointe vers un collecteur qui accepte POST, et si vous avez aussi configuré le mécanisme Reporting-Endpoints / Report-To que la directive moderne report-to exige.
Une CSP remplace-t-elle les autres protections ? Non. C’est une couche parmi d’autres : continuez à échapper vos sorties, gardez les cookies avec HttpOnly et Secure, conservez HSTS. Le vérificateur d’en-têtes de sécurité de ce site note l’ensemble.
