J’ai retiré une intégration Brevo d’un site corporate où elle était installée depuis des années. Nous ne nous en servions plus. Son code était resté dans le site.
Dans une autre vérification, j’ai retrouvé un domaine expiré dans une liste de sources autorisées. La recherche du domaine le donnait à vendre pour 50 dollars. La configuration continuait donc de désigner un nom que quelqu’un d’autre pouvait reprendre.
Ces deux découvertes, dans un contexte que je garde anonyme, ne démontrent pas une compromission. Elles établissent deux restes d’anciennes décisions : du code tiers conservé sans usage, et une autorisation portant sur un domaine expiré. Leur portée dépend de ce que le navigateur ou l’application peut encore en faire.
Fermer le compte d’un outil ne retire pas son script
Le chargement d’un script externe suit une chaîne précise : le navigateur reçoit une page du site, y trouve l’adresse du script, puis demande le code à cette adresse. Tant que cette référence reste active dans la page, le navigateur peut effectuer la demande. Le fait que l’équipe marketing ait cessé d’utiliser l’outil ne modifie pas le contenu de la page.
L’incident Brevo du 14 septembre 2026 donne un exemple documenté de ce qui peut passer par cette chaîne. Le compte rendu de Brevo décrit une clé API Cloudflare compromise, puis l’injection de code malveillant dans des contenus distribués aux visiteurs, dont des scripts intégrés sur les sites de clients. Les fichiers d’origine n’étaient pas modifiés.
J’ai découvert cet incident après avoir retiré notre intégration. Cela ne permet de dater le retrait ni avant ni après l’attaque, et je ne dispose pas d’élément établissant une compromission de notre site.
Pour vérifier le retrait d’un tel script, la preuve attendue se trouve dans les pages et les requêtes du navigateur : la référence a disparu des pages concernées et la navigation ne déclenche plus son chargement. Une absence de connexion au tableau de bord du prestataire ne répond pas à cette vérification.
Un domaine autorisé n’est pas nécessairement un domaine chargé
La politique de sécurité des contenus, ou CSP, permet de limiter les sources de certaines ressources. Une entrée dans cette politique donne une permission. Elle ne crée pas, à elle seule, une demande vers le domaine.
Pour examiner le risque, deux cas doivent être distingués. Ce sont des configurations illustratives, pas une reconstitution de celle de l’entreprise.
| Configuration | Conséquence |
|---|---|
| Domaine autorisé, aucune ressource demandée | L’autorisation existe, mais ne provoque aucun chargement à elle seule |
| Domaine autorisé et script demandé à cette adresse | Le navigateur peut demander le script au détenteur actuel du domaine, sous réserve des autres contrôles |
Dans le second cas, reprendre le domaine peut permettre de changer le contenu fourni à cette adresse. Dans le premier, il faut encore un chemin de chargement ou un autre défaut pour utiliser la permission. La directive précise aussi ce qui est permis : une autorisation d’image ne vaut pas autorisation de JavaScript. La documentation de script-src décrit ce dernier contrôle.
La capture de ma recherche montre un prix d’achat et de renouvellement de 50 dollars. Elle ne montre ni une ressource chargée ni une attaque, et ne renseigne pas la disponibilité actuelle du domaine. Elle documente le motif pour lequel l’entrée devait être réexaminée.
L’icône de l’application ne décrit pas ses droits
J’ai aussi rencontré des centaines d’applications accumulées dans Microsoft 365 et HubSpot, dont des applications inutilisées. Le décompte ne permet pas de dire combien conservent un accès à des données.
Une démonstration simple consiste à comparer deux permissions fictives. « Lire le nom du compte connecté » et « lire ses contacts » peuvent apparaître derrière deux applications installées. Dans le second cas, l’examen doit porter sur les contacts accessibles et la portée de l’autorisation. Dans le premier, attribuer ce même accès aux contacts serait une erreur.
La revue doit donc conserver les permissions effectivement trouvées, l’identité à laquelle elles s’appliquent et l’usage qui les justifie. Microsoft décrit la revue et la révocation des permissions d’applications. Un inventaire de noms ou une capture d’icônes ne remplace pas ces informations.
Le retrait a besoin d’un résultat observable
Pour ces trois types de retrait, les résultats attendus se vérifient à des endroits différents.
| Objet retiré | Vérification attendue |
|---|---|
| Script dans le site | Référence retirée et absence de chargement sur les pages concernées |
| Domaine autorisé en CSP | Entrée absente de la politique réellement servie, sans casser les ressources conservées |
| Permission d’application | Autorisation révoquée, puis vérification de l’accès concerné selon le service et ses délais de révocation |
Une suppression peut également casser un usage encore actif. Avant de retirer une permission, il faut retrouver le traitement qui s’en sert. Après le retrait, c’est ce traitement et l’accès supprimé qui doivent être contrôlés. Le nom de l’application barré dans un tableur ne permet de conclure ni sur l’un ni sur l’autre.
Trois constats, trois suites différentes
L’intégration Brevo n’avait plus d’usage et a été retirée. Le domaine expiré figurait dans une configuration de confiance et nécessitait un examen de ses chargements possibles. Les applications accumulées demandaient une lecture de leurs permissions avant de pouvoir qualifier leur accès.
Rassembler ces objets sous l’étiquette « outils inutilisés » aurait masqué ces différences. L’un était du code à retirer du site, un autre une autorisation à revoir, les derniers un ensemble de droits à examiner application par application.
La dette de sécurité décrite ici tient à ces décisions restées incomplètes après la fin d’un usage. Elle rejoint les cinq visages de la dette technique, avec une contrainte propre : une permission oubliée ne devient pas inoffensive parce qu’elle ne provoque aucun ticket support.