Un widget de chat, un formulaire, un outil d’analytics ou un SDK chargé depuis un domaine tiers devient une extension de la surface de confiance du site. Si cette dépendance est compromise au niveau d’un CDN ou d’une couche edge, le navigateur peut recevoir du code malveillant sans qu’aucun fichier de votre hébergement n’ait changé.
Ce qui s’est passé chez Brevo
Le 14 septembre 2026, Brevo a subi un incident de chaîne d’approvisionnement distinct de son incident SSO précédent. D’après le post-mortem de l’entreprise, relayé par plusieurs analyses, une clé API Cloudflare longue durée et trop privilégiée, présente dans du code applicatif, a été récupérée. L’attaquant a pu créer un Worker et modifier des réponses à la périphérie du réseau Cloudflare.
Pendant environ cinq heures et demie, du contenu malveillant a ainsi pu être injecté dans des pages Brevo mais aussi dans certains scripts Brevo intégrés sur des sites clients, notamment des composants de formulaires et de conversation. Les visiteurs pouvaient recevoir une fausse vérification de type ClickFix ; des scénarios observés ciblaient aussi les administrateurs WordPress connectés.
Pourquoi le serveur d’origine pouvait rester propre
Un contrôle d’intégrité effectué uniquement sur les fichiers du serveur répond à une question utile : « mes fichiers ont-ils changé ? ». Il ne répond pas forcément à la question plus importante pour l’utilisateur : « qu’est-ce que le navigateur reçoit réellement ? ».
Un CDN, un reverse proxy, un Worker edge ou un service tiers peut transformer la réponse après sa sortie du serveur d’origine. Dans ce cas, comparer les fichiers locaux ou le dépôt Git peut ne rien révéler. Il faut compléter ces contrôles par des observations externes de la réponse délivrée.
Un script tiers étend votre frontière de confiance
Un script JavaScript exécuté dans une page dispose souvent d’un accès très large au contexte de cette page. Selon son emplacement et les protections présentes, il peut lire ou modifier le DOM, déclencher des requêtes, charger d’autres ressources ou présenter une interface trompeuse à l’utilisateur.
Le risque ne signifie pas qu’il faut supprimer tous les services tiers. Il signifie qu’il faut les inventorier, réduire ceux qui sont inutiles et surveiller les changements significatifs.
Les contrôles qui deviennent utiles
- Inventorier les scripts et domaines tiers réellement chargés par les pages importantes.
- Détecter l’apparition d’un nouveau script ou domaine, ainsi que les suppressions ou changements inhabituels.
- Observer le site depuis l’extérieur pour contrôler la réponse réellement livrée au navigateur, pas seulement l’origine.
- Déployer une Content Security Policy progressivement, idéalement d’abord en mode report-only, afin de limiter les sources de scripts autorisées.
- Utiliser Subresource Integrity lorsque la ressource est statique et compatible avec ce mécanisme ; ce contrôle n’est pas adapté à tous les scripts dynamiques.
- Limiter les clés API et jetons au strict nécessaire, éviter les secrets dans le code et préférer des identifiants courts ou facilement révocables.
- Conserver un historique des dépendances et des changements afin de distinguer une évolution prévue d’une anomalie.
Le signal à surveiller n’est pas seulement « le site répond »
Un HTTP 200, un certificat TLS valide et des fichiers d’origine inchangés ne suffisent pas à garantir que le contenu envoyé au navigateur est celui attendu. Les dépendances web et la chaîne de diffusion font partie de la surface à superviser.
Ce que cela change pour une surveillance comme InfraCheck
Pour TechAtelier, cet incident renforce une piste produit déjà cohérente avec la découverte d’actifs : ajouter progressivement un inventaire des dépendances web visibles depuis l’extérieur. L’objectif n’est pas d’analyser chaque ligne de JavaScript, mais d’identifier les scripts et domaines tiers, de conserver une référence et de signaler les changements qui méritent une vérification.
Cette approche peut ensuite être corrélée aux autres signaux : CSP, nouveaux domaines, modification de contenu, exposition d’un service et historique des incidents. Elle permet de réduire les angles morts sans transformer chaque changement légitime en alerte critique.
Checklist rapide pour un site
- listez les scripts externes présents sur les pages sensibles ;
- supprimez les intégrations devenues inutiles ;
- vérifiez votre CSP et les domaines autorisés ;
- contrôlez les changements depuis un point de vue externe ;
- protégez les comptes CDN et les API avec le moindre privilège ;
- faites remonter toute nouvelle dépendance inattendue comme un événement à examiner.
Sources
- Brevo — Post-mortem de l’incident ClickFix
- Sansec — Brevo supply chain attack
- BleepingComputer — Brevo supply-chain attack
Publié le 18 septembre 2026. Les faits décrits correspondent aux informations publiques disponibles à cette date.