En bref : limites de la conformité CSP
- CSP est une défense native critique du navigateur, mais elle ne suffit pas à elle seule pour assurer la conformité PCI DSS 4.0.1. L'attaque de la chaîne d'approvisionnement Polyfill.io de 2024 a réussi sur des centaines de milliers de sites où la CSP était correctement configurée.
- La limite fondamentale est que la CSP autorise des domaines, pas l'intégrité du code. Si un domaine de confiance est compromis (comme Polyfill.io l'a été), la CSP autorise tout de même le code malveillant à se charger et à s'exécuter.
- PCI DSS 4.0.1 §6.4.3 et §11.6.1 exigent explicitement des capacités allant au-delà de la CSP : inventaire des scripts avec justification métier, vérification de l'intégrité à chaque chargement, et détection des modifications non autorisées des pages de paiement.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
Qu'est-ce qu'une Content Security Policy (CSP) ?
Une Content Security Policy (CSP) est un en-tête de réponse HTTP qui indique aux navigateurs quelles sources de scripts, feuilles de style et frames sont autorisées à se charger. Elle atténue les risques de XSS en bloquant les scripts inline non autorisés et les chargements externes non autorisés. La CSP constitue une base nécessaire, mais elle ne détecte pas les anomalies comportementales dans les scripts autorisés, ne surveille pas ce que font les scripts au moment de l'exécution, et ne satisfait pas à l'exigence de PCI DSS 6.4.3 concernant un inventaire des scripts autorisés avec justification métier.
La Content Security Policy (CSP) est une fonctionnalité de sécurité fournie par les navigateurs web qu'un propriétaire de site peut utiliser pour définir un ensemble de règles contrôlant les ressources (scripts, styles, images, etc.) pouvant être chargées et exécutées par le navigateur. C'est ce que l'on appelle le côté client, tout au bout de la chaîne d'approvisionnement web.
Correctement configurée, elle aide à prévenir un large éventail d'attaques. Mais ces trois premiers mots font toute la différence.
Elle peut aider à prévenir le cross-site scripting (XSS) : en restreignant les sources depuis lesquelles les scripts peuvent être chargés, la CSP bloque les scripts malveillants injectés dans une page web. Par exemple, si une politique CSP spécifie script-src 'self', seuls les scripts provenant du domaine propre du site peuvent s'exécuter. Elle protège également contre le clickjacking : la directive frame-ancestors empêche qu'un site soit intégré dans des iframes sur des domaines non autorisés, et elle limite les attaques par injection de données en contrôlant quelles images, polices et médias sont autorisés à se charger.
Comme nous allons le voir, ce n'est pas tout à fait le cas en réalité.
L'objectif de la CSP (correctement configurée)
Défense contre les contenus tiers malveillants
Les sites web s'appuient souvent sur des contenus tiers, comme des outils d'analyse ou des scripts publicitaires, qui peuvent devenir des vecteurs d'attaque s'ils sont compromis. La CSP minimise ce risque en restreignant le contenu à des sources pré-approuvées et de confiance, protégeant ainsi votre site des vulnérabilités présentes dans les bibliothèques tierces.
Prévention de l'exfiltration de données
Les scripts malveillants conçus pour extraire des données sensibles et les envoyer vers des domaines non autorisés constituent une menace permanente. La CSP agit comme un rempart, bloquant ces scripts et garantissant la sécurité des données des utilisateurs.
Protection contre les attaques de la chaîne d'approvisionnement
Combinée à la Subresource Integrity (SRI), la CSP valide les scripts et styles tiers pour s'assurer qu'ils n'ont pas été altérés lors de leur livraison. Cela constitue une protection théorique contre les compromissions de la chaîne d'approvisionnement.
Contrôle des comportements dynamiques non souhaités
Les directives CSP comme script-src, style-src et les restrictions sur unsafe-eval empêchent l'exécution de code généré ou modifié dynamiquement. Cela réduit la surface d'attaque en limitant les exploits qui reposent sur eval() ou les scripts inline.
Légèreté et haute configurabilité
Transmise via des en-têtes côté serveur, la CSP a un impact minimal sur les performances de l'application. Sa flexibilité permet des configurations sur mesure, ce qui la rend adaptée à un large éventail de cas d'usage et de besoins architecturaux.
Les défis et les limites de la CSP
Pourquoi alors la CSP a-t-elle mauvaise réputation ? En théorie, elle semble être une solution idéale. Un outil puissant pour contrôler totalement ce que les navigateurs sont autorisés à charger sur un site web.
En pratique, cependant, la réalité est bien loin de tenir cette promesse.
La CSP est un mécanisme de défense complémentaire, pas une solution autonome, et elle s'accompagne de défis et de limites significatifs qui peuvent nuire à son efficacité, voire donner un faux sentiment de sécurité.
Complexité de mise en œuvre
Élaborer une CSP efficace pour des applications web modernes est une tâche difficile. Les sites web dépendent souvent de nombreux domaines tiers pour l'analyse, les CDN, la publicité et les polices, ce qui rend presque impossible la création d'une politique stricte sans casser certaines fonctionnalités. La gestion des directives comme script-src, style-src et img-src sur des sources diverses devient effectivement ingérable, en particulier pour les applications volumineuses et en constante évolution.
Impossibilité de bloquer des scripts spécifiques
La CSP fonctionne sur un modèle de liste d'autorisation, qui permet les ressources provenant de domaines de confiance mais ne peut pas bloquer des scripts ou ressources individuels provenant de ces domaines.
Un exemple rapide : si vous autorisez un domaine comme cdn.example.com, la CSP ne peut pas empêcher l'exécution de scripts malveillants qui y sont hébergés.
Les mises à jour récentes de la CSP introduisent une fonctionnalité pour remédier à cette limitation en utilisant la Subresource Integrity (SRI) intégrée à la directive script-src. Cela permet d'inscrire des scripts spécifiques sur liste d'autorisation à l'aide de hachages de leur contenu, garantissant que seule la version exacte et vérifiée d'un script peut être chargée.
Bien que puissante en théorie, cette approche présente un inconvénient majeur : toute mise à jour du script invalide le hachage, provoquant l'échec de la vérification SRI et rendant le script non fonctionnel.
Pour les scripts fréquemment mis à jour, comme ceux des outils marketing, cela rend la fonctionnalité de hachage inutile. À moins de travailler avec des scripts garantis statiques, ce mécanisme est essentiellement inutilisable.
Charge de maintenance élevée
Les politiques CSP nécessitent des mises à jour fréquentes pour prendre en compte :
- Les nouveaux scripts, styles ou ressources pour les fonctionnalités ou pages ajoutées.
- Les modifications des domaines ou services tiers.
- Les facteurs externes, comme un changement d'API tierce, qui peuvent casser une politique auparavant fonctionnelle.
Un outil de surveillance dédié est nécessaire pour détecter ces mises à jour.
Risques liés aux dépendances tierces
Autoriser des ressources tierces dans les politiques CSP revient intrinsèquement à faire confiance à ces domaines externes pour qu'ils restent sécurisés. Or, des scripts compromis ou malveillants provenant de tiers de confiance peuvent tout de même s'exécuter, contournant entièrement les protections CSP.
Cette dépendance constitue elle-même une vulnérabilité critique dans le modèle CSP.
Nous l'avons constaté lors de l'attaque Polyfill de 2024, où c'est exactement ce qui s'est produit. Plus d'un demi-million de sites web faisaient confiance à un seul domaine pour injecter un script sur leur site. Même ceux disposant d'une stratégie CSP robuste en ont été victimes.
Difficultés avec les scripts et styles inline
Par défaut, la CSP bloque les scripts et styles inline, ce qui est une mesure de sécurité judicieuse. Mais là encore, des problèmes se posent.
- De nombreux frameworks (React, Angular, etc.) et systèmes legacy s'appuient fortement sur les scripts inline, rendant leur application difficile sans une refactorisation importante.
- De nombreux outils marketing fournissent des exemples utilisant des balises
<script>inline pour charger des bundles JavaScript externes. Bien que ces scripts puissent s'exécuter depuis des fichiers séparés, les exemples les intègrent souvent directement, compliquant l'application de la CSP et introduisant des risques potentiels. - Pour y remédier, les développeurs ont souvent recours à unsafe-inline, ce qui compromet la sécurité de la CSP en autorisant tout le contenu inline.
Abus des directives d'assouplissement
Pour éviter de casser des fonctionnalités, les développeurs doivent en réalité affaiblir les politiques CSP. Une façon paradoxale de faire primer la fonctionnalité sur la sécurité.
unsafe-inline: autorise les scripts et styles inline, annulant les principaux objectifs de sécurité de la CSP.unsafe-eval: permet l'utilisation de eval() et de méthodes similaires, qui sont très facilement exploitables.*(caractère générique) : accorde l'accès à n'importe quel domaine, annulant ainsi effectivement la valeur de la politique.
Débogage des violations CSP
Diagnostiquer les problèmes liés à la CSP est extrêmement chronophage et frustrant.
- Les navigateurs consignent les violations CSP dans la console, mais les journaux manquent souvent de contexte suffisant pour identifier la cause racine.
- Le débogage de politiques trop strictes qui cassent des fonctionnalités demande un effort considérable, poussant les développeurs à assouplir la politique et à compromettre la sécurité.
Rupture des fonctionnalités existantes
Comme mentionné précédemment, des politiques CSP strictes peuvent perturber des composants essentiels.
- Les intégrations tierces comme les outils d'analyse, la publicité ou les widgets sociaux.
- Les applications legacy qui dépendent de scripts inline, de styles ou de ressources chargées dynamiquement. Pour rétablir les fonctionnalités, les développeurs assouplissent fréquemment les restrictions, compromettant la sécurité visée.
Incohérences entre navigateurs
L'application de la CSP varie d'un navigateur à l'autre, ce qui aggrave encore la situation.
- Les navigateurs plus anciens peuvent ignorer certaines directives entièrement.
- Certaines directives, comme worker-src ou navigate-to, ne bénéficient pas d'un support universel, ce qui limite leur efficacité.
Absence de reporting standardisé
Bien que la CSP prenne en charge le signalement des violations, il n'existe pas de format ou d'outil universellement accepté pour traiter ces rapports, ce qui rend plus difficile pour les équipes de les analyser et d'agir efficacement.
Contournements d'exfiltration faciles pour les politiques CSP incomplètes
L'une des plus grandes vulnérabilités des configurations CSP incomplètes est l'absence de la directive default-src. Sans elle, les politiques CSP peuvent être contournées pour exfiltrer des données via des mécanismes comme le prefetching.
Bien que default-src soit censée définir des règles de repli, la spécification CSP précise que le prefetching n'est pas régi par sa propre directive, donc sans default-src, les liens de prefetch contournent entièrement la CSP. Notre analyse de sites web explorés a révélé qu'un nombre surprenant d'entre eux ne disposaient pas de default-src, les laissant vulnérables à cet exploit. Et connect-src n'aide pas non plus : même un connect-src bien configuré ne peut pas empêcher l'exfiltration par prefetch, car il ne s'applique pas à ce type de connexions.
Évitez la CSP, faites plutôt ceci
La CSP présente des avantages réels sur le papier. L'utiliser dans un environnement réel devient rapidement une tâche fastidieuse. Pourtant, la sécurité côté client est de plus en plus répandue.
Lorsque vous recherchez un outil de sécurité côté client, vérifiez qu'il ne repose pas uniquement sur la CSP comme base de surveillance des ressources en la configurant en mode « report-only ». Ces solutions dépendent principalement de la CSP pour suivre et signaler les comportements des ressources, n'offrant qu'une capacité de blocage limitée en fonctionnalité supplémentaire.
Si cela est probablement suffisant pour la conformité, cela vous expose à de sérieux problèmes en cas d'attaque.
cside propose des solutions de sécurité modernes qui ne dépendent pas de la CSP, pour une approche plus efficace de la protection côté client. Nous avons développé un service qui surveille l'ensemble des scripts de votre site et peut détecter et bloquer de manière proactive le code malveillant.
Pas besoin de vérifications manuelles ni de rapports.
Vous pouvez commencer gratuitement ou nous contacter.
