Clé API exposée dans une application : autopsie d'un défaut, et 600 000 dollars chez METR

Un testeur nous a envoyé son projet parce que sa base de données en ligne refusait de se brancher. En l'ouvrant, nous avons vu sa clé d'accès écrite en clair dans son application. Ce que ça coûte ailleurs, ce que nous avons changé le jour même.

Une clé API exposée dans une application est un mot de passe de service laissé en clair, lisible par quiconque ouvre le fichier. L'institut d'évaluation METR raconte (Update on Security at METR, 31 août 2026) qu'une clé volée dans une application publiée sans authentification effective a servi, en trois semaines, à consommer des crédits valant environ 600 000 dollars.

Ce qu'est une clé, en une phrase

Votre application a souvent besoin de parler à un service extérieur : une base de données en ligne, un envoi de courriels, un paiement. Ce service ne connaît pas votre application, il connaît une chaîne de caractères qui prouve que la demande vient bien de vous. Quiconque possède cette chaîne peut faire ce que votre application fait : lire vos clients, écrire à leur place, dépenser sur votre compte. Elle doit donc vivre ailleurs que dans le code, dans un coffre que le programme interroge au moment de s'en servir.

Ce qui est arrivé à un institut d'évaluation

METR évalue des systèmes d'IA pour vivre. L'histoire ne concerne donc pas une petite entreprise distraite. En mars 2026, des attaquants ont volé une clé d'accès laissée dans une application déployée dont l'authentification ne fonctionnait plus, et ont consommé pendant trois semaines des crédits qui auraient valu environ 600 000 dollars (le fournisseur les avait offerts à METR, la perte financière est donc restée théorique). Un second épisode, début mai, a visé un visualiseur public. Deux enseignements tiennent en peu de mots : une protection peut s'éteindre sans prévenir, et une consommation anormale peut courir trois semaines avant qu'on la voie.

Notre propre défaut, trouvé par un testeur

Fin août, un testeur de notre beta nous a envoyé son projet, une application mobile qu'il avait construite lui-même, parce que sa base de données en ligne refusait de se brancher. L'adresse de sa base de données en ligne et sa clé privée étaient écrites en dur dans le code. Notre part de responsabilité était double. D'abord nous ne le lui avions jamais dit : sur un logiciel existant repris dans Maestro, la carte qui parle de la base en ligne ne pouvait pas apparaître, parce qu'elle dépendait d'une étape que ce parcours ne franchit jamais. Ensuite rien n'empêchait cette clé de partir en sauvegarde en ligne. Il n'avait rien fait de sot : son assistant IA avait écrit le code de cette façon, l'application fonctionnait, et aucun écran ne lui a jamais signalé la différence entre une clé rangée et une clé collée dans un fichier qui voyage.

Ce que nous avons changé, et ce que nous avons refusé de faire

Le rangement de la clé est proposé, jamais imposé : le produit vous montre où elle est, explique le risque, et le déplacement se fait sur votre accord. Quand une clé privée traîne dans le code, la sauvegarde en ligne est refusée si sa destination est publique ou d'origine inconnue, et signalée si elle est privée. Et la carte qui parle de votre base en ligne apparaît désormais sur un logiciel repris, sans dépendre d'une étape que ce parcours ne franchit jamais. Tout cela a été construit et publié le 30 août 2026, dans la version 0.1.13, et vous pouvez lire ce que nous savons de vos données sur la page qui leur est consacrée. Nous avons écarté deux réponses plus faciles. Déplacer la clé nous-mêmes, sans demander : un outil qui touche seul aux accès d'un service en production fabrique des pannes que son propriétaire ne sait pas expliquer. Et bloquer tout le monde par principe : beaucoup de projets repris ont une bonne raison d'avoir une clé publique à cet endroit, et un outil qui crie au loup à chaque ouverture finit ignoré.

Pourquoi cela se produit si souvent

Veracode a mesuré, dans son rapport du 28 juillet 2026, que 44 % des tâches de génération de code produisent une vulnérabilité, un taux quasi identique à celui de l'année précédente. Un assistant qui écrit vite écrit ce qui marche, et une clé collée dans le fichier marche. Rien à l'écran ne distingue une application saine d'une application ouverte : les deux se lancent, les deux affichent vos données, et c'est bien le problème. Le contrôle doit donc venir de l'outil, au moment où le code est écrit et au moment où il part.

En pratique, ce soir

Cherchez dans les fichiers de votre projet les mots key, token et secret, puis regardez ce qui suit : une longue suite de caractères sans signification est une clé. La recherche de texte de votre système suffit, il n'y a aucun code à lire. Si vous en trouvez une dans un fichier qui part avec l'application, régénérez cette clé chez le fournisseur, puis rangez la nouvelle dans les réglages du service. Vérifiez ensuite ce que votre base accepte de montrer sans mot de passe : le test se fait en deux minutes. Un testeur nous a rendu ce service par accident ; personne ne vous garantit le même hasard.