Un outil de mesure de la performance web peut-il devenir une porte d'entrée pour des pirates ? L'incident survenu chez DebugBear fin octobre prouve que oui. Si votre site utilise son script de Real User Monitoring (RUM) pour suivre les Core Web Vitals, la consigne de l'éditeur est simple : retirez-le immédiatement.

Ce qui s'est passé

Le 29 octobre, DebugBear a signalé un incident de sécurité touchant son infrastructure. Selon l'éditeur, des attaquants ont compromis ses enregistrements DNS en passant par son bureau d'enregistrement de nom de domaine. Ils ont ainsi pu servir du JavaScript malveillant à la place du script légitime.

D'après ses premières investigations, l'attaque visait le site d'un seul client, et rien n'indique que ses systèmes internes aient été compromis. La société a toutefois indiqué ne plus pouvoir recevoir les e-mails envoyés à son domaine pendant l'incident.

La société de cybersécurité Hudson Rock a identifié le code malveillant sur une URL de script utilisée par Polymarket. Ce code exploitait la session d'utilisateurs déjà connectés. Polymarket a confirmé que le script avait vendu des positions et transféré des fonds depuis les portefeuilles de certains utilisateurs, sans avoir besoin de leur mot de passe.

Le vrai risque : la session des visiteurs connectés

C'est la leçon principale pour tous les sites. Un script tiers s'exécute avec les mêmes droits que votre propre code. Sur un site où les visiteurs sont connectés (e-commerce, espace client, back-office), il peut agir en leur nom. Un simple outil de mesure devient alors un vecteur d'attaque.

Que faire si vous utilisez DebugBear

  • Retirez le script RUM de vos templates, plugins et gestionnaires de balises, videz les caches et vérifiez qu'il ne se charge plus.
  • Invalidez les sessions exposées et réinitialisez les mots de passe, en commençant par les comptes administrateurs.
  • Recherchez les modifications non autorisées survenues pendant la période où le script était actif.
  • Prévenez vos équipes techniques et sécurité : l'incident ne relève pas seulement du SEO.

Les bonnes pratiques pour tous les scripts tiers

Au-delà de DebugBear, cet épisode invite à auditer chaque script externe : est-il indispensable ? Peut-il être chargé uniquement sur les pages publiques, et jamais dans les espaces connectés ? Une Content Security Policy et l'attribut d'intégrité (SRI), lorsque le fournisseur le permet, limitent les dégâts.

La mesure de la performance reste nécessaire, mais elle peut aussi s'appuyer sur des données publiques comme le CrUX. Pour comprendre les écarts entre outils, lisez notre article sur Lighthouse 13.6 et PageSpeed Insights. La question du tracking rejoint aussi celle des données transmises aux plateformes publicitaires, que nous abordons à propos des adresses IP dans GTM côté serveur. Enfin, pensez à vérifier votre propriété dans la Search Console : Google y envoie les alertes de sécurité et d'actions manuelles.

Source : Search Engine Journal (Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript). Article original rédigé par la rédaction de Socialcomarket.