Une Content Security Policy (CSP) est un en-tête HTTP qui détermine quelles ressources un navigateur peut charger sur votre site web, telles que les scripts, feuilles de style et images. Vous réduisez ainsi considérablement le risque de cross-site scripting (XSS) et d’autres attaques par injection. Dans cet article, vous découvrirez ce que fait exactement la CSP, comment configurer l’en-tête via .htaccess ou Plesk, et comment éviter les erreurs courantes.
Qu’est-ce qu’une Content Security Policy
La CSP est une couche de sécurité qui indique aux navigateurs depuis quels domaines ils peuvent charger du contenu. Sans CSP, un attaquant peut injecter du JavaScript malveillant via une vulnérabilité de votre site, qui sera alors exécuté sans restriction. Avec une politique correctement configurée, le navigateur bloque tout ce qui n’est pas explicitement autorisé, même si le code malveillant est déjà présent dans le HTML.
La politique est transmise sous forme d’en-tête de réponse HTTP Content-Security-Policy. Vous pouvez la configurer au niveau du serveur, via une balise meta dans le HTML, ou via votre CMS. Pour la plupart des sites web, la configuration au niveau du serveur est la plus sûre, car elle ne peut pas être écrasée par un script compromis.
Directives CSP et exemples
Une CSP se compose de directives qui indiquent quel type de contenu peut provenir de quelle source. Les principales sont :
- default-src : règle par défaut pour tous les types de contenu s’il n’existe pas de directive plus spécifique.
- script-src : détermine d’où peut provenir le JavaScript.
- style-src : détermine les sources autorisées pour le CSS.
- img-src : gère les images.
- font-src : gère les polices.
- connect-src : gère les connexions AJAX, WebSocket et fetch.
- frame-ancestors : détermine quels sites peuvent intégrer votre page dans un iframe.
Un exemple simple qui n’autorise que le contenu provenant de votre propre domaine, avec une exception pour Google Fonts :
Content-Security-Policy: default-src 'self'; style-src 'self' fonts.googleapis.com; font-src fonts.gstatic.com;
Content-Security-Policy-Report-Only) avant d’activer l’en-tête réel. Vous verrez ainsi quelles sources sont bloquées sans casser votre site.Configurer la CSP sur votre serveur
Vous pouvez ajouter l’en-tête CSP de différentes manières, selon la configuration de votre serveur.
Via .htaccess
Ajoutez la ligne suivante au fichier .htaccess situé à la racine de votre site web : Header set Content-Security-Policy "default-src 'self';". Cette méthode fonctionne directement sur les serveurs Apache et LiteSpeed.
Via Plesk
Connectez-vous à Plesk, accédez à votre domaine et ouvrez Paramètres Apache & nginx. Vous pouvez y ajouter manuellement l’en-tête CSP sous « Directives supplémentaires » sans devoir modifier votre .htaccess.
Via une balise meta
Si vous ne pouvez pas modifier les paramètres du serveur, vous pouvez aussi placer la politique dans le HTML : <meta http-equiv="Content-Security-Policy" content="default-src 'self';">. Attention : cette méthode ne permet pas de configurer frame-ancestors ni report-uri.
Extension par type de contenu
Ajoutez progressivement des directives supplémentaires pour les scripts, styles, images et polices jusqu’à ce que toutes les fonctionnalités de votre site fonctionnent à nouveau, sans devoir ouvrir la politique de manière trop large.
Tester et erreurs courantes
Testez toujours votre politique dans la console du navigateur ; vous y verrez immédiatement quelles sources sont bloquées avec un message d’erreur clair. Les erreurs courantes sont :
- L’utilisation de
unsafe-inlinepour les scripts, ce qui annule en grande partie la protection contre le XSS. - Oublier que les services externes tels que les analytics, widgets de chat ou réseaux publicitaires doivent également être explicitement autorisés.
- Ne pas tenir compte des sous-domaines qui nécessitent des règles distinctes.
- Mettre la politique en production directement sans d’abord tester avec Report-Only.
Vérifiez également que vos formulaires liés aux e-mails et le contenu intégré, comme celui via des widgets d’e-mail professionnel ou des formulaires de contact, fonctionnent toujours correctement après la configuration de la politique. Si vous rencontrez des difficultés, consultez la base de connaissances pour plus d’exemples de configuration ou contactez le support.
Questions fréquentes
Une CSP va-t-elle immédiatement casser mon site web ?
Pas si vous testez d’abord avec Report-Only. Une politique mal configurée peut bloquer des scripts ou des styles, vérifiez donc toujours la console du navigateur avant de passer en production.
La CSP fonctionne-t-elle avec un CDN ?
Oui, ajoutez le domaine de votre CDN aux directives concernées, par exemple script-src ou style-src, afin que les fichiers provenant de cette source soient autorisés.
La CSP est-elle obligatoire pour un bon score de sécurité ?
Non obligatoire, mais recommandée. Elle réduit l’impact des vulnérabilités XSS et est souvent prise en compte positivement par les scanners de sécurité.
Puis-je combiner la CSP avec un SSL gratuit ?
Oui, la CSP et le SSL fonctionnent indépendamment mais se complètent bien : le SSL sécurise le transport, la CSP limite le contenu pouvant être chargé.
Dois-je configurer la CSP pour mon nom de domaine ou par sous-domaine ?
Par sous-domaine séparément, car chaque sous-domaine peut avoir ses propres en-têtes et configuration. Si vous gérez plusieurs noms de domaine, configurez une politique adaptée pour chaque domaine.
Conclusion
Une Content Security Policy est un moyen puissant mais précis de protéger votre site web contre le XSS et les contenus indésirables. Commencez par Report-Only, construisez la politique directive par directive, et testez minutieusement avant de passer en production. Vous évitez ainsi de bloquer des fonctionnalités légitimes.