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.

Astuces

  • 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.

FAQ

CSP indique précisément au navigateur quelles sources sont autorisées à fournir les scripts, images, styles et autres ressources de la page. Tout ce qui ne figure pas dans la liste blanche — y compris les scripts en ligne — est empêché de se charger ou de s'exécuter, ce qui réduit fortement le risque qu'une attaque XSS exécute un script contrôlé par un attaquant.

Oui : les sources de type nonce ('nonce-') et de type hash ('sha256-') fonctionnent toutes les deux. En ajoutant à une balise script un attribut nonce correspondant à la valeur indiquée dans l'en-tête de réponse, vous pouvez autoriser cette balise précise tout en continuant à bloquer tout autre script en ligne non autorisé.

CSP a bloqué une ressource parce que son origine ne figurait pas dans la liste blanche. La console du navigateur affiche un message du type « Refused to load...because it violates the following Content Security Policy directive », qui indique l'origine exacte en cause ; ajoutez cette origine à la liste blanche de la directive concernée pour résoudre le problème.

Généralement non. default-src ne sert que de valeur de repli pour les directives que vous n'avez pas définies explicitement. Les directives à haut risque comme script-src et object-src doivent chacune être configurées explicitement et de façon stricte, car elles représentent une surface d'attaque bien plus importante que la plupart des autres directives.

Les deux indiquent où le navigateur doit envoyer les rapports de violation, mais report-uri est la directive la plus ancienne et pointe directement vers une URL de rapport. report-to s'appuie sur la Reporting API plus récente et référence à la place un groupe nommé défini dans un en-tête Report-To distinct. Comme la prise en charge par les navigateurs diffère entre les deux, il est courant de spécifier les deux pour des raisons de compatibilité.
ツールくん

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 ».

→ Lire les anecdotes connexes

→ Voir toutes les anecdotes

Plus d'outils dans cette catégorie