Validateur d'en-tête CSP
Collez la valeur d'un en-tête Content-Security-Policy pour valider en une seule fois ses directives et ses valeurs de source. Détecte les réglages risqués comme unsafe-inline, l'absence d'un default-src de secours et les fautes de frappe dans les noms de directives, et affiche les sources autorisées de chaque directive dans une vue détaillée.
Examiner le contenu d'un en-tête CSP
Une Content-Security-Policy est une unique longue chaîne séparée par des points-virgules, et la suivre à l'œil fait aisément manquer ce qu'elle a de risqué. Cet outil prend la valeur que vous collez, la décompose en directives et en sources, met au jour les réglages dangereux, les déclarations absentes et les fautes d'orthographe, et expose ce que chaque directive autorise réellement.
**Une directive mal orthographiée est, de tous les cas, le plus traître.** Les navigateurs passent en silence sur les directives qu'ils ne reconnaissent pas, si bien qu'écrire `scipt-src` au lieu de `script-src` **ne provoque aucune erreur tandis que cette partie de la politique continue de ne rien faire du tout.** Tout aussi facile à manquer est l'absence de `default-src` : sans elle, toute directive que vous n'avez pas détaillée demeure sans restriction et une brèche s'ouvre dans la défense. Et glisser `unsafe-inline` dans script-src **réduit à presque rien le blocage des scripts en ligne, qui est la raison première d'adopter CSP.**
Comment s'en servir
- Collez la valeur de l'en-tête CSP Saisissez une chaîne de la forme `default-src 'self'; script-src ...` telle quelle.
- Essayez d'abord les exemples Un bon et un mauvais exemple sont fournis, de sorte que vous voyez en quoi les verdicts diffèrent avant de commencer.
- Lisez les points relevés **`unsafe-inline`, un `default-src` manquant et les fautes d'orthographe sont tous signalés.**
- Parcourez les sources autorisées par directive Vous voyez d'un coup d'œil d'où le chargement est permis.
Astuces pour en tirer le meilleur parti
- CSP est habituellement transmise sous forme d'en-tête de réponse HTTP, mais elle peut aussi être définie via une balise
<meta http-equiv="Content-Security-Policy">(certaines directives comme report-uri n'y ont toutefois aucun effet). - Avant de déployer CSP en production, essayez d'abord l'en-tête Content-Security-Policy-Report-Only : il ne fait que collecter les rapports de violation, ce qui permet d'évaluer l'impact sur les fonctionnalités existantes sans rien casser.
- Les caractères génériques (*) et 'unsafe-inline' facilitent le développement, mais ils sapent l'essentiel de la protection XSS de CSP. Resserrez toujours une politique trop permissive avant de passer en production.
- Répéter deux fois la même directive ne fusionne pas les valeurs : seule la première occurrence est prise en compte. Pour ajouter ou remplacer des sources, regroupez-les toutes dans une seule directive.
- La console DevTools de votre navigateur affiche les ressources bloquées sous forme d'un message rouge « Refused to load... », c'est donc le premier endroit à consulter pour déboguer une CSP trop stricte.
Dans quels cas s'en servir
Pour introduire une CSP pour la première fois
Vous confirmez que la politique écrite fait bien ce que vous vouliez, avant même qu'elle n'approche la production.
Pour faire l'inventaire d'une politique existante
**Une politique grossie par accumulation garde volontiers des autorisations pour des domaines que plus personne n'utilise.**
Pour passer du simple signalement à l'application
Une valeur essayée sous `Content-Security-Policy-Report-Only` s'examine avant d'être appliquée.
Pour épauler une revue de code
Collez la politique modifiée et confirmez qu'elle ne s'en trouve pas affaiblie.
Vocabulaire de CSP
- Directive
- Une entrée telle que `script-src` ou `img-src` qui **énonce d'où une catégorie donnée de ressource peut être chargée.**
- Default-src
- La valeur de repli pour toute directive non énoncée séparément. **Omettez-la et toute catégorie que vous n'avez pas détaillée reste sans restriction.**
- 'self'
- Une expression de source n'autorisant que les chargements depuis la même origine.
- 'unsafe-inline'
- Une expression de source autorisant les scripts et les styles écrits directement dans le HTML. **Elle abandonne presque entièrement la défense contre le XSS, aussi conseille-t-on de la remplacer par un nonce ou une empreinte.**
- Nonce
- Un procédé qui inscrit une valeur aléatoire à usage unique à la fois dans la balise du script et dans la politique, afin que les deux se répondent. C'est la manière sûre d'autoriser du code en ligne.
- Frame-ancestors
- Une directive nommant qui peut insérer votre site dans un cadre. **Elle succède à X-Frame-Options.**
FAQ
Anecdote — Pourquoi CSP existe : échapper les sorties n'a jamais suffi à lui seul pour stopper le XSS
Content Security Policy trouve son origine dans une idée avancée par Robert Hansen vers 2004, que l'ingénieur de Mozilla Brandon Sterne a ensuite transformée en spécification formelle à partir d'environ 2008, aboutissant à la première Candidate Recommendation du W3C (Level 1) en 2012. Le cross-site scripting (XSS) était alors l'une des vulnérabilités web les plus préoccupantes, et il est devenu évident que s'appuyer uniquement sur la rigueur des développeurs — « échapper correctement chaque sortie » — ne constituait pas une défense suffisamment robuste. CSP a été conçu comme un mécanisme de défense en profondeur permettant au navigateur lui-même d'imposer des restrictions sur l'origine autorisée des scripts.
CSP Level 2 a introduit des autorisations basées sur un nonce ou un hash pour les scripts en ligne, permettant aux sites d'autoriser du code en ligne spécifique sans recourir à 'unsafe-inline'. Level 3 a ensuite ajouté 'strict-dynamic', qui accorde automatiquement sa confiance aux scripts chargés dynamiquement par un script déjà approuvé, réduisant considérablement la charge de maintenance des listes blanches basées sur les hôtes pour les sites de grande taille.
Google continue de déployer une CSP stricte basée sur des nonces dans ses propres services à grande échelle, et a publié à ce sujet des recherches concluant que les listes blanches basées sur les hôtes peuvent souvent être contournées, alors que les politiques basées sur un nonce ou un hash sont en pratique bien plus efficaces. Ce constat est aujourd'hui largement cité comme une bonne pratique en matière de CSP et souligne que la véritable décision de conception ne consiste pas seulement à choisir « quelles valeurs interdire », mais d'abord « sur quelle stratégie de liste blanche s'appuyer ».