Parmi toutes les protections qu'un site web peut mettre en place, la Content Security Policy est l'une des plus efficaces, et pourtant l'une des moins utilisées. Elle tient en un seul en-tête HTTP, mais elle peut bloquer une grande partie des attaques par injection de script. Voici comment elle fonctionne et comment l'adopter sans casser votre site.
Qu'est-ce qu'une content security policy ?
Une content security policy, souvent abrégée CSP, est une liste de règles que votre serveur envoie au navigateur. Ces règles disent au navigateur d'où il a le droit de charger des scripts, des feuilles de style, des images, des polices ou des cadres. Tout ce qui ne figure pas dans la liste est bloqué.
L'intérêt est immédiat : si un pirate parvient à injecter un script malveillant dans une page, par exemple via un champ de commentaire mal filtré, le navigateur refusera de l'exécuter, car sa source n'est pas autorisée. On parle de défense en profondeur : même si une faille existe dans le code, son exploitation est fortement limitée.
Les attaques que la CSP empêche
La protection la plus connue concerne les attaques XSS (cross-site scripting), qui figurent depuis des années dans le classement des failles les plus fréquentes établi par l'OWASP. Mais une CSP bien réglée apporte d'autres bénéfices :
- Elle empêche le détournement de votre site dans un cadre (clickjacking) grâce à la directive frame-ancestors ;
- Elle bloque les anciens plugins comme Flash, avec la directive object-src ;
- Elle force le passage en HTTPS des ressources chargées en HTTP ;
- Elle limite les fuites de données vers des domaines inconnus.
Commencer par une politique de base
Il n'est pas nécessaire d'écrire immédiatement une politique complète et stricte. Une première étape utile, et sans risque pour l'affichage, consiste à activer quelques directives simples : interdire l'affichage du site dans un cadre externe, bloquer les plugins, verrouiller la balise base et demander le passage automatique en HTTPS.
C'est exactement ce que je mets en place par défaut sur les sites que j'héberge. Cette base protège déjà contre plusieurs attaques courantes, sans rien changer au fonctionnement des pages.
Aller plus loin progressivement
Pour une protection complète contre les scripts injectés, il faut lister les sources autorisées pour les scripts et les styles. C'est là que les choses se compliquent : outils de statistiques, polices Google, cartes, vidéos intégrées, boutons de réseaux sociaux… chaque service externe doit être déclaré.
La bonne méthode consiste à utiliser d'abord le mode « rapport uniquement ». Dans ce mode, le navigateur n'applique pas les règles mais signale tout ce qu'il aurait bloqué. Vous pouvez ainsi observer pendant quelques jours ce que votre site charge réellement, ajuster la politique, puis passer en mode bloquant quand plus aucune alerte légitime n'apparaît. La documentation de MDN sur la CSP détaille toutes les directives disponibles.
Les pièges classiques
Le premier piège est le script écrit directement dans la page. Une CSP stricte les bloque par défaut. Il faut alors soit les déplacer dans des fichiers séparés, soit les autoriser individuellement avec un jeton unique ou une empreinte. C'est un travail de nettoyage, mais il améliore aussi la qualité du code.
Le second piège concerne les CMS comme WordPress, dont les extensions injectent souvent du code dans les pages. Une politique trop stricte peut casser un formulaire ou un module de paiement. D'où l'importance de tester en mode rapport avant d'appliquer.
Vérifier votre configuration
Plusieurs outils gratuits analysent les en-têtes de sécurité d'un site et attribuent une note. Ils permettent de vérifier en quelques secondes si votre politique est bien envoyée et si elle contient des faiblesses évidentes, comme une autorisation trop large des scripts.
Mon conseil
Activez au minimum une content security policy de base dès aujourd'hui : elle ne coûte rien et ne casse rien. Pour un site qui collecte des données personnelles ou des paiements, investissez ensuite quelques heures dans une politique complète, construite à partir des rapports du navigateur. C'est l'un des meilleurs rapports effort-sécurité que je connaisse.
