En bref : pourquoi ne pas déployer les scripts d'analytique sur tout le site
- La commodité a fait fuiter : Les guides d'onboarding disent encore aux développeurs de coller les tags d'analytique dans _document.js et de passer à autre chose, mais cette commodité est exactement la manière dont Kaiser Permanente a livré 13,4 millions de dossiers de membres à des fournisseurs tiers qui n'étaient jamais censés les voir.
- PCI le rend obligatoire : PCI DSS 4.0 rend l'inventaire et l'intégrité des scripts obligatoires d'ici mars 2025. L'agent JavaScript first-party de cside surveille le comportement à l'exécution de chaque script tiers sur 100 % des sessions, sur chaque page, avec un blocage autonome en plus.
- Cadrez avant d'auditer : Avant le prochain audit de framework, décidez si les pixels d'analytique et marketing ont vraiment besoin d'un accès au DOM sur vos pages de connexion, de KYC et de compte, ou si un déploiement limité à la page ferme gratuitement un vecteur de la chaîne d'approvisionnement.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
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. Les scripts tiers sont utilisés partout, mais rarement examinés, surveillés ou sécurisés.
Les risques du déploiement de scripts tiers sur l'ensemble du site
Examinons maintenant certains des problèmes liés au déploiement global de scripts.
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 exige la surveillance des scripts tiers d'ici mars 2025 ; c'est donc le moment de démarrer et de mettre cside en place. Cela vous rend conforme et ajoute un blocage autonome en plus 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 que cside les récupère et les analyse. 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 chaque script servi, sur 100 % des sessions, sur chaque page.
Pour en savoir plus sur la façon dont notre approche se distingue, lisez ceci.
