Les scripts tiers sont souvent déployés sur l'ensemble d'un site, généralement injectés dans les balises head des frameworks web comme Next.js via le fichier _document.js. Cette implémentation généralisée, bien que pratique pour les développeurs et souvent recommandée par les guides d'intégration, signifie que ces scripts s'exécutent sur la totalité du site. C'est plus simple à mettre en place, mais cela introduit aussi des risques de sécurité et des problèmes de performance souvent négligés.
La récente fuite de données de Kaiser Permanente illustre les dangers d'une mauvaise gestion des scripts tiers. Comme nous l'avons écrit dans notre analyse complète de l'incident :
Le 29 avril, le géant de la santé Kaiser Permanente a divulgué une fuite de données touchant 13,4 millions de membres actuels et anciens. L'incident trouve son origine dans une gestion inadéquate de scripts tiers. Kaiser Permanente utilisait des codes de suivi pour surveiller la façon dont ses membres naviguaient sur son site web et ses applications mobiles. Certaines de ces pages contenaient des données de santé sensibles, ce qui a conduit les scripts tiers à transmettre par inadvertance des informations à des fournisseurs tiers qui n'étaient pas censés les recevoir. Bien que la violation ne résulte pas d'un détournement de script, elle met en évidence une négligence significative dans la gestion des scripts tiers.
Mais le problème va au-delà de la fuite d'informations potentiellement sensibles vers des fournisseurs tiers. Il reflète une réalité plus large : les scripts tiers sont fréquemment utilisés, mais rarement examinés ou surveillés. Et encore moins sécurisés.
Les risques du déploiement de scripts tiers sur l'ensemble du site
Maintenant que nous avons vu pourquoi les scripts sont souvent déployés globalement, examinons les problèmes qu'ils engendrent.
1. Accès non contrôlé aux données
C'est précisément ce qui s'est produit dans l'affaire Kaiser Permanente. Lorsqu'ils sont déployés globalement, les scripts tiers ont souvent accès à des données sensibles sur les pages web. Cela peut inclure les saisies utilisateur, les informations de session et d'autres données confidentielles. Sans contrôles stricts, ces scripts peuvent fuiter des données vers des parties non autorisées, de manière accidentelle ou malveillante. Dans le cas de Kaiser Permanente et d'autres acteurs du secteur de la santé, les scripts tiers ne sont souvent pas conformes à la loi Health Insurance Portability and Accountability Act (HIPAA), ce qui fait de toute fuite de données vers ces fournisseurs un incident grave.
2. Attaques sur la chaîne d'approvisionnement
Les attaquants peuvent compromettre la chaîne d'approvisionnement web en ciblant des services tiers et en injectant du code malveillant dans des scripts. Ces scripts compromis peuvent ensuite propager des logiciels malveillants, voler des données ou effectuer d'autres actions nuisibles sur chaque site où ils sont déployés. C'est déjà problématique en soi, mais la situation est encore pire lorsque les scripts sont déployés globalement et ont accès à davantage de données et d'utilisateurs.
Bien entendu, cside protège contre ce type d'attaque.
3. Applications web monopage (SPA)
Les SPA gèrent très mal les scripts. À moins qu'un développeur n'effectue un rechargement complet de la page lors de la navigation vers une page sensible, tous les scripts précédemment chargés restent présents. Tout script tiers chargé initialement continue de s'exécuter et peut potentiellement accéder à des données sensibles tout au long de la session de l'utilisateur, sauf en cas de rechargement complet de la page, ce qui augmente le risque de fuites de données et d'accès non autorisés.
4. Risques de conformité et réglementaires
Les organisations doivent se conformer à diverses réglementations en matière de protection des données, telles que le RGPD, la HIPAA et PCI DSS 4.0. Une gestion inadéquate des scripts tiers peut entraîner une non-conformité, avec à la clé des amendes importantes et des répercussions juridiques.
PCI DSS 4.0 exigeant la surveillance des scripts tiers d'ici mars 2025, le moment est venu de démarrer et de mettre cside en place. Non seulement cela vous rend conforme, mais cela va encore plus loin en introduisant un blocage autonome pour vous protéger davantage.
5. Problèmes de performance et de stabilité
Peut-être moins critique, mais clairement perceptible : les scripts tiers mal optimisés ralentissent les sites web. Toute interruption ou problème lié au service tiers peut avoir un impact direct sur le fonctionnement et la disponibilité du site hôte. Un site qui se charge en 1 seconde affiche un taux de conversion 3 fois supérieur à celui d'un site qui met 5 secondes à charger.
Protégez-vous contre ces risques
À l'instar des directives PCI DSS 4.0, nous sommes partisans d'une surveillance continue de la sécurité et encourageons tous les propriétaires de sites à l'adopter. Nous pensons que l'appliquer à toutes les pages est l'approche la plus efficace.
Vous pouvez le faire en utilisant notre offre gratuite. Elle est en libre-service et vous permet d'être conforme et protégé en quelques minutes. Nous sommes bien sûr toujours disponibles pour vous aider si nécessaire.
Notre script réécrit les sources des autres scripts de votre site afin de les faire transiter par le proxy cside. Il effectue également certaines détections côté navigateur. Cela permet à cside de gérer le flux de requêtes entre l'utilisateur et le script tiers sans ajouter de latence. Dans certains cas, il peut même améliorer les performances en mettant en cache les scripts statiques.
Cela offre une visibilité complète sur les scripts servis, pour 100 % des sessions et sur toutes les pages.
Pour en savoir plus sur la façon dont notre approche se distingue, lisez ceci.
