En résumé
- Le JavaScript tiers est omniprésent (médiane : 22 scripts par page) et s'exécute avec les mêmes privilèges que votre propre code.
- Si un fournisseur est compromis, votre site web l'est aussi : des scripts malveillants peuvent accéder aux données des utilisateurs, aux champs de formulaire, aux cookies et aux jetons de session.
- Les bonnes pratiques pour la sécurité des scripts tiers comprennent : un inventaire des scripts en temps réel + un accès aux scripts selon le principe du moindre privilège + des vérifications d'intégrité avec détection des changements et alertes + une surveillance continue à l'exécution.
- Certaines de ces bonnes pratiques peuvent être mises en œuvre avec des contrôles navigateur comme le CSP ou une surveillance manuelle, mais une protection réelle et la conformité à des référentiels comme le RGPD et PCI DSS reposent sur un outil spécialisé comme cside.
Bonnes pratiques pour sécuriser les scripts tiers sur les pages web
Selon le Web Almanac 2024 de HTTP Archive, 92 % des pages web utilisent des ressources tierces. Les fichiers JavaScript sont le type de ressource tierce le plus courant, représentant environ 30 % des requêtes tierces. En 2024, la page mobile médiane effectuait 22 requêtes JavaScript par page. Au 90e percentile, ce chiffre montait à 68. Sur desktop, les chiffres sont du même ordre, avec respectivement 23 et 70.
Une fois autorisés, les scripts s'exécutent librement. Lorsqu'un fournisseur est compromis ou qu'un CDN est altéré, du code malveillant peut s'infiltrer dans le navigateur des utilisateurs. Dans cet article, nous examinons des bonnes pratiques concrètes pour la sécurité du JavaScript tiers, sans sacrifier la performance ni les fonctionnalités.
1. Inventaire complet des scripts et visibilité
Un « inventaire » en temps réel de chaque script servi aux utilisateurs dans le navigateur est un bon point de départ. L'inventaire doit indiquer l'origine du code : un fournisseur ou une bibliothèque tierce que vous avez choisi, ou un obscur fournisseur de quatrième niveau ?
pas d'inventaire = pas de visibilité = pas de contrôle
Les pages de paiement présentent un risque particulièrement élevé. Dans un monde idéal, il n'y aurait aucun script tiers sur les pages de paiement. Risque zéro. Mais ce n'est pas réaliste. Les processeurs de paiement et autres outils de caisse nécessitent du JavaScript pour le flux de paiement.
Une plateforme de protection côté client comme cside supprime le travail manuel en générant et en maintenant automatiquement un inventaire des scripts en temps réel.
2. Accès aux scripts selon le principe du moindre privilège
Pour chaque script, vérifiez quelles données il touche et demandez-vous : pourquoi ? Surveillez attentivement les scripts qui accèdent à des données sensibles telles que les champs de formulaire, les cookies ou les jetons de session. Tous les scripts ne nécessitent pas des privilèges complets, mais sans contrôles en place, les scripts ont un accès direct aux informations sensibles.
Pourquoi un script d'analyse aurait-il besoin d'accéder aux données de paiement ? Les pixels marketing n'ont aucune raison de lire les identifiants et mots de passe, n'est-ce pas ?
Le CSP pour restreindre le chargement des scripts
Par défaut, les navigateurs exécutent n'importe quel script, y compris les scripts chaînés. Restreindre l'accès aux données est essentiel pour votre défense. Une Content Security Policy (CSP) définit l'origine autorisée du code : par exemple, uniquement vos propres serveurs et des sources tierces figurant sur liste blanche. Vous définissez ces règles dans vos en-têtes HTTP ou votre HTML, et le navigateur les applique.
Le CSP vérifie uniquement l'origine du code, pas ce qu'il fait une fois en cours d'exécution. Le code est dynamique et se met à jour. Si du code malveillant est chargé depuis une source de confiance, votre CSP ne le bloquera pas.
Le CSP est un point de départ, mais il est loin de constituer une défense complète. Les CSP sont entièrement basés sur le domaine source depuis lequel un script se charge, et n'examinent pas les comportements des scripts.
Avec cside, vous pouvez définir des politiques qui restreignent l'accès des scripts par comportement. Autrement dit, des scripts spécifiques peuvent être autorisés à lire les cookies ou les champs de formulaire, tandis que tous les autres scripts (y compris les scripts approuvés) sont bloqués dans l'exécution d'actions risquées dans le navigateur.
3. Vérifier l'intégrité, détecter les changements et configurer des alertes
Votre mécanisme de suivi doit également surveiller les modifications et mises à jour des scripts. Un script peut être sain et sûr un jour, puis voir son intégrité compromise lors d'une mise à jour.
Un contrôle natif du navigateur pour cela est la Subresource Integrity (SRI). La SRI ajoute un hachage cryptographique aux scripts ou aux balises <link>. Elle garantit l'intégrité du code. Lorsque le navigateur charge un script, il vérifie le hachage. Si un seul octet diffère, le navigateur n'exécutera pas le code. La SRI fonctionne bien pour protéger les ressources tierces statiques et détecte les modifications au niveau du CDN. Mais la SRI ne fonctionne pas avec les scripts dynamiques, dont dépendent la plupart des sites web modernes.
Une solution éditeur (comme cside) peut être utilisée pour surveiller l'intégrité des scripts à travers différentes couches d'un moteur de détection. Les équipes de sécurité sont automatiquement alertées en cas d'anomalie comportementale ou de compromission avérée d'un fournisseur dans la chaîne d'approvisionnement.
4. Utiliser une surveillance à l'exécution axée sur le comportement des scripts
Les « scanners distants » sont faciles à mettre en œuvre mais offrent une visibilité limitée. Des recherches de l'ISACA concluent que ces outils de test de sécurité ratent les menaces où le code est chargé de manière conditionnelle pour éviter ce type de scans. Les solutions de type « scanner » sont également limitées à la détection, avec peu de capacité à bloquer le code malveillant.
L'examen du code tiers avant son déploiement en production présente également des limites. De nombreux scripts sont approuvés une seule fois, rarement réexaminés, mais changent fréquemment. Un script peut passer la revue avant sa publication, puis se voir insérer du code malveillant des mois plus tard.
La surveillance à l'exécution détecte les scripts compromis provenant de sources de confiance. Lorsqu'un script commence soudainement à lire des champs de formulaire ou à effectuer des requêtes réseau, vérifiez votre inventaire et bloquez-le. La surveillance à l'exécution consiste à observer les scripts en action. Même des aspects comme la manipulation du DOM peuvent être suivis grâce à la surveillance à l'exécution.
Mettre cela en œuvre via des outils développés en interne devient rapidement irréalisable. Vous finissez par créer votre propre antivirus et investissez des ressources considérables dans un projet qui n'est pas aligné avec votre cœur de métier. Il existe de nombreuses solutions clé en main, comme cside, qui exécutent automatiquement la surveillance à l'exécution sur vos pages et organisent les données dans des tableaux de bord et des alertes clairs.
5. Alignement avec la conformité
La conformité a la réputation d'engendrer une paperasse chronophage. Les contrôles côté client sont exigés par un nombre croissant de référentiels, notamment le RGPD, PCI DSS et CCPA/CPRA.
Assurez-vous que vos activités de traitement par des scripts tiers sont conformes aux exigences de ces référentiels : transparence, limitation des finalités et protection des données. Cela signifie que vous devez comprendre exactement comment les scripts tiers se comportent, afin de pouvoir les déclarer avec précision dans vos mentions d'information. Par défaut, les scripts ne doivent collecter que les données nécessaires (en lien avec le principe du moindre privilège) et des mesures de sécurité doivent protéger les utilisateurs contre l'exfiltration de données côté client.
Un bon point de départ consiste à examiner les DPA de chaque fournisseur tiers que vous ajoutez à votre site. Ceux-ci précisent comment ils entendent traiter les données collectées auprès de vos utilisateurs. Pour s'assurer que leur activité réelle est conforme aux attentes, un outil de surveillance des scripts tiers comme cside peut être déployé.
Pourquoi les sites web dépendent du JavaScript tiers
Il est judicieux pour les bâtisseurs de ne pas fabriquer leurs propres briques, mais de s'appuyer sur des experts pour les matériaux et l'ingénierie. Il en va de même pour les développeurs web : ils utilisent des outils tiers pour l'analyse, les paiements en ligne, les widgets et d'autres fonctionnalités qui rendent les sites web dynamiques et interactifs.
Il n'est pas nécessaire de réinventer des solutions qui existent déjà. Des outils spécialisés font le travail, permettant aux équipes web de se concentrer sur leur cœur de métier plutôt que sur l'interface utilisateur, les tests A/B, les flux de paiement en ligne, l'analyse, le suivi de localisation, etc.
Pourquoi les scripts tiers représentent un risque majeur pour la sécurité côté client
Le problème des privilèges des scripts tiers
Voici le problème : dans le navigateur, tout JavaScript est traité de la même façon.
Le DOM ne fait pas la distinction entre votre code et celui d'un fournisseur. Les scripts tiers ont le même accès aux données utilisateur et aux champs de formulaire que votre propre code propriétaire. Ils peuvent lire les champs de formulaire, accéder aux cookies, modifier le contenu de la page et effectuer des requêtes réseau.
C'est précisément la vulnérabilité que recherchent les acteurs malveillants.
Le problème de la chaîne d'approvisionnement des scripts tiers
Cela signifie que si l'infrastructure d'un fournisseur est compromise, des scripts malveillants peuvent être injectés directement dans votre site web.
En médiane, 21 % des scripts sur les pages mobiles sont injectés dynamiquement. Au 90e percentile, le nombre de scripts atteint même 70 %. Sur desktop, les chiffres sont comparables.
Les scripts injectés peuvent créer un angle mort en matière de sécurité car ils ne sont pas dans le périmètre des outils de sécurité web traditionnels. Cela implique également que les scripts tiers injectés dynamiquement peuvent eux-mêmes injecter des scripts supplémentaires que vous n'avez jamais approuvés.
une violation chez l'un de vos fournisseurs = une violation de votre application
Pire encore : un script compromis peut se propager à tous les sites web qui l'utilisent. Une seule faille dans un script largement utilisé peut se transformer en une attaque massive sur la chaîne d'approvisionnement.
