Politique de sécurité du contenu
Silktide vérifie que chaque page déclare une Politique de sécurité du contenu (CSP), une mesure de sécurité standard qui indique aux navigateurs quelles sources de scripts, d’images et d’autres contenus la page est autorisée à utiliser.
Une Politique de sécurité du contenu (CSP) est fournie sous forme d’ ou de balise meta, par exemple:
Content-Security-Policy: default-src 'self'; script-src 'self' scripts.example.com
Cet exemple indique au navigateur de ne charger du contenu que depuis votre propre domaine, ainsi que des scripts depuis un hôte de confiance.
Pourquoi c’est important
Sans CSP, une page exécute tout ce qu’on lui fournit. Si un attaquant parvient à injecter un script — via une balise tierce compromise, un champ de commentaire vulnérable ou un réseau publicitaire détourné — le navigateur l’exécute avec un accès complet à la page, y compris à tout ce que vos visiteurs saisissent. Cette famille d’attaques, le cross-site scripting (XSS), reste l’un des moyens les plus courants par lesquels les sites web sont compromis.
Une CSP est le filet de sécurité côté navigateur : le contenu injecté provenant d’une source non approuvée ne se charge tout simplement pas. Elle documente aussi avec quels tiers vos pages communiquent, ce qui aide lors de la démonstration de conformité à des réglementations de confidentialité comme le .
Comment le corriger
- Dressez la liste des sources légitimes depuis lesquelles vos pages chargent du contenu : votre propre domaine, votre , vos outils d’analyse, les polices et les médias intégrés.
- Rédigez une politique n’autorisant que ces sources. Commencez de façon stricte, par exemple
default-src 'self', puis ajoutez des sources spécifiques par type de contenu (script-src,img-src,style-src) selon les besoins. - Configurez votre serveur web, votre plateforme d’hébergement ou votre CDN pour envoyer la politique sous forme de l’en-tête
Content-Security-Policysur chaque page. Si vous ne pouvez pas modifier les en-têtes, une balise<meta http-equiv=\"Content-Security-Policy\">dans l’en-tête de la page fonctionne aussi, même si l’en-tête est préférable. - Testez avant de l’appliquer : envoyez d’abord la politique en
Content-Security-Policy-Report-Onlyet surveillez la console du navigateur pour voir le contenu qui aurait été bloqué. Notez que ce contrôle recherche l’en-tête appliqué ; une politique en mode report-only ne le valide pas.
Comment Silktide effectue ce test
- Charge chaque page et recueille ses en-têtes HTTP ainsi que toute balise meta
http-equivdans la page, que les navigateurs traitent de la même manière. - Recherche une valeur
Content-Security-Policyà l’un ou l’autre endroit. - Signale la page si ni l’un ni l’autre n’est présent ou si la valeur est vide.
- Silktide n’évalue pas la qualité de la politique — uniquement son existence.
Dépannage
J’ai défini une politique mais le contrôle échoue toujours
Vérifiez que l’en-tête apparaît sur les pages exactement analysées — les politiques sont parfois configurées uniquement pour la page d’accueil ou pour un hôte virtuel. Vous pouvez voir les en-têtes qu’une page renvoie dans les outils de développement de votre navigateur, sous l’onglet Réseau.
Une CSP va-t-elle casser mon site web ?
Une politique trop stricte peut bloquer vos propres scripts ou styles. C’est pourquoi tester d’abord avec Content-Security-Policy-Report-Only est fortement recommandé : cela signale les violations sans rien bloquer.