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 deux 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 peut bloquer efficacement les scripts malveillants injectés dans une page web.
Par exemple, si une politique CSP spécifie script-src 'self', elle garantit que seuls les scripts provenant du domaine propre au site sont exécutés.
La protection contre le clickjacking : En utilisant la directive frame-ancestors, la CSP empêche votre site d'être intégré dans des iframes sur des domaines non autorisés, réduisant ainsi le risque d'attaques par clickjacking.
Les attaques par injection de données : La CSP contrôle le chargement des ressources telles que les images, les polices et les médias, réduisant les risques liés à l'injection ou à la manipulation de ressources.
Comme nous allons le voir, la réalité est tout autre.
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 loin de tenir cette promesse.
La CSP n'est pas une solution autonome, mais un mécanisme de défense complémentaire qui s'accompagne de défis et de limites significatifs. Ces lacunes 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 concret : si vous autorisez un domaine comme cdn.example.com, la CSP ne peut pas empêcher l'exécution de scripts malveillants hébergés là-bas.
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 invalidera 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 — cette fonctionnalité de hachage devient inutilisable. Sauf si vous travaillez avec des scripts garantis statiques, ce mécanisme est pratiquement inutilisable, ce qui limite son applicabilité dans le monde réel.
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 à 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 met en évidence 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.
- * : Accorde l'accès à n'importe quel domaine, neutralisant de fait 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 principales vulnérabilités des configurations CSP incomplètes réside dans l'omission de la directive default-src. Sans cette directive, les politiques CSP peuvent être contournées pour exfiltrer des données via des mécanismes comme le prefetching.
- Le rôle de default-src : Bien qu'elle soit destiné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. Sans default-src, les liens de prefetch contournent entièrement la CSP.
- Une lacune bien réelle : Notre analyse des sites web crawlés a révélé qu'un nombre surprenant d'entre eux ne disposent pas de default-src, les laissant vulnérables à cet exploit.
- Connect-src n'est pas suffisant : 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 offre des avantages indéniables 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 incontournable.
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, offrant une approche plus fluide et plus efficace de la protection côté client. Nous avons développé un service proxy 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.
