Discussion :

[Alex]

Les clés API Google n'étaient pas secrètes, mais Gemini a changé les règles car il utilise les mêmes clés pour accéder à vos données, un pirate peut accéder à vos données et vous facturer l'utilisation du LLM

Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte.

Gemini, anciennement Bard, est un assistant conversationnel développé par l'entreprise Google. Pour générer du texte, il se base sur une famille de grands modèles de langage également appelée Gemini, introduite au public le 7 décembre 2023. Gemini est l'acronyme de Generalized Multimodal Intelligence Network. Gemini peut comprendre et interagir avec l'audio et la vidéo, et générer du texte (poésie, scripts, pièces musicales, courriels, lettres, etc.), du code, des traductions (entre plus de 100 langues). Il peut produire plusieurs types de contenu créatif (images, dessins, sons, musique, vidéos…), aider des chercheurs en analysant des données ou en générant des hypothèses.

Pendant plus de dix ans, Google a répété aux développeurs que les clés API Google (comme celles utilisées dans Maps, Firebase, etc.) n'étaient pas secrètes. Mais ce n'est plus vrai : Gemini accepte les mêmes clés pour accéder à vos données privées. Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte. Même Google disposait d'anciennes clés API publiques, qu'il considérait comme non sensibles, mais qui pouvait être utiliser pour accéder au Gemini interne de Google.

Le problème fondamental

Google Cloud utilise un seul format de clé API (AIza...) à deux fins fondamentalement différentes : l'identification publique et l'authentification sensible.

Pendant des années, Google a explicitement indiqué aux développeurs que les clés API pouvaient être intégrées en toute sécurité dans le code côté client. La liste de contrôle de sécurité de Firebase stipule que les clés API ne sont pas des secrets.

Remarque : celles-ci sont très différentes des clés JSON de compte de service utilisées pour alimenter GCP.

La documentation JavaScript de Google Maps invite les développeurs à coller leur clé directement dans le code HTML.

Cela semble logique. Ces clés ont été conçues comme des identifiants de projet à des fins de facturation et peuvent être soumises à des restrictions supplémentaires (contournables) telles que la liste blanche des référents HTTP. Elles n'ont pas été conçues comme des identifiants d'authentification.

Puis Gemini est arrivé.

Lorsque vous activez l'API Gemini (Generative Language API) sur un projet Google Cloud, les clés API existantes dans ce projet (y compris celles qui se trouvent dans le JavaScript public de votre site web) peuvent accéder silencieusement aux points de terminaison sensibles de Gemini. Sans avertissement. Sans boîte de dialogue de confirmation. Sans notification par e-mail.

Cela crée deux problèmes distincts :

Extension rétroactive des privilèges. Vous avez créé une clé Maps il y a trois ans et l'avez intégrée dans le code source de votre site web, exactement comme Google vous l'avait demandé. Le mois dernier, un développeur de votre équipe a activé l'API Gemini pour un prototype interne. Votre clé Maps publique est désormais un identifiant Gemini. Toute personne qui la récupère peut accéder à vos fichiers téléchargés, à votre contenu mis en cache et faire grimper votre facture d'IA. Personne ne vous en a informé.

Paramètres par défaut non sécurisés. Lorsque vous créez une nouvelle clé API dans Google Cloud, elle est par défaut « sans restriction », ce qui signifie qu'elle est immédiatement valable pour toutes les API activées dans le projet, y compris Gemini. L'interface utilisateur affiche un avertissement concernant « l'utilisation non autorisée », mais l'architecture par défaut est largement ouverte.

Résultat : des milliers de clés API qui ont été déployées comme des jetons de facturation inoffensifs sont désormais des identifiants Gemini actifs sur l'internet public.

Ce qui fait de cela une élévation de privilèges plutôt qu'une mauvaise configuration, c'est la séquence des événements.

1. Un développeur crée une clé API et l'intègre dans un site web pour Maps. (À ce stade, la clé est inoffensive.)

2. L'API Gemini est activée sur le même projet. (Désormais, cette même clé peut accéder à des points de terminaison Gemini sensibles.)

3. Le développeur n'est jamais averti que les privilèges de la clé ont changé en arrière-plan. (La clé est passée d'un identifiant public à un identifiant secret).

Bien que les utilisateurs puissent restreindre les clés API Google (par service API et application), la vulnérabilité réside dans la posture par défaut non sécurisée (CWE-1188) et l'attribution incorrecte des privilèges (CWE-269) :

- Mise à niveau implicite de la confiance : Google a appliqué rétroactivement des privilèges sensibles à des clés existantes qui étaient déjà légitimement déployées dans des environnements publics (par exemple, des bundles JavaScript).

- Absence de séparation des clés : une conception sécurisée de l'API nécessite des clés distinctes pour chaque environnement (clés publiables vs clés secrètes). En s'appuyant sur un format de clé unique pour les deux, le système s'expose à des compromissions et à la confusion.

Échec des paramètres par défaut sécurisés : l'état par défaut d'une clé générée via le panneau API GCP permet d'accéder à l'API Gemini sensible (en supposant qu'elle soit activée). Un utilisateur qui crée une clé pour un widget de carte génère sans le savoir un identifiant capable d'effectuer des actions administratives.

Ce qu'un pirate peut faire

L'attaque est très simple. Un pirate visite votre site web, consulte le code source de la page et copie votre clé AIza... à partir de l'intégration Maps. Il exécute ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"

Au lieu d'un message d'erreur 403 Forbidden, il obtient un message 200 OK. À partir de là, le pirate peut :

- Accéder à des données privées. Les points de terminaison /files/ et /cachedContents/ peuvent contenir des ensembles de données téléchargés, des documents et du contenu mis en cache. Tout ce que le propriétaire du projet a stocké via l'API Gemini est accessible.

- Faire grimper votre facture. L'utilisation de l'API Gemini n'est pas gratuite. En fonction du modèle et de la fenêtre contextuelle, un acteur malveillant qui maximise les appels API pourrait générer des milliers de dollars de frais par jour sur un seul compte victime.

Épuiser vos quotas. Cela pourrait entraîner l'arrêt complet de vos services Gemini légitimes.

Le pirate ne touche jamais à votre infrastructure. Il se contente de récupérer une clé sur une page web publique.

2 863 clés actives sur l'Internet public

Pour comprendre l'ampleur du problème, Truffle Security a analysé l'ensemble de données Common Crawl de novembre 2025, une archive massive (~700 TiB) de pages web publiques contenant du code HTML, JavaScript et CSS provenant de l'ensemble de l'Internet. Ils ont identifié 2 863 clés API Google actives vulnérables à ce vecteur d'escalade de privilèges.

Il ne s'agit pas seulement de projets parallèles menés par des amateurs. Parmi les victimes figuraient de grandes institutions financières, des sociétés de sécurité, des cabinets de recrutement internationaux et, notamment, Google lui-même. Si les équipes d'ingénieurs du fournisseur ne parviennent pas à éviter ce piège, il est irréaliste d'attendre de chaque développeur qu'il le contourne correctement.

Preuve de concept : les propres clés de Google

Les chercheurs ont fourni à Google des exemples concrets tirés de sa propre infrastructure pour illustrer le problème. L'une des clés testées était intégrée dans le code source d'une page du site web public d'un produit Google. En consultant les archives Internet, ils ont confirmé que cette clé était accessible au public depuis au moins février 2023, bien avant l'existence de l'API Gemini. La page ne comportait aucune logique côté client tentant d'accéder à des points de terminaison Gen AI. Elle était uniquement utilisée comme identifiant de projet public, ce qui est la norme pour les services Google.

Ils ont testé la clé en accédant au point de terminaison /models de l'API Gemini (dont Google a confirmé qu'il était concerné) et avons obtenu une réponse 200 OK répertoriant les modèles disponibles. Une clé déployée il y a des années à des fins tout à fait bénignes avait silencieusement obtenu un accès complet à une API sensible sans aucune intervention des développeurs.

Chronologie de la divulgation

Truffle Security a signalé ce problème à Google via son programme de divulgation des vulnérabilités le 21 novembre 2025.

- 21 novembre 2025 : ils ont soumis le rapport au VDP de Google.

- 25 novembre 2025 : Google a initialement déterminé que ce comportement était intentionnel. Ils ont contesté cette décision.

- 1er décembre 2025 : après avoir fourni des exemples tirés de la propre infrastructure de Google (y compris des clés sur les sites web des produits Google), le problème a suscité l'intérêt en interne.

- 2 décembre 2025 : Google a reclassé le rapport de « Problème client » à « Bug », a augmenté son niveau de gravité et a confirmé que l'équipe produit évaluait une solution. Ils ont demandé la liste complète des 2 863 clés exposées.

- 12 décembre 2025 : Google a communiqué son plan de remédiation. L'entreprise a confirmé la mise en place d'un pipeline interne pour détecter les clés divulguées, a commencé à restreindre l'accès des clés exposées à l'API Gemini et s'est engagée à traiter la cause profonde avant notre date de divulgation.

- 13 janvier 2026 : Google a classé la vulnérabilité comme « Escalade des privilèges d'un seul service, LECTURE » (niveau 1).

- 2 février 2026 : Google a confirmé que l'équipe travaillait toujours à la résolution de la cause profonde.

- 19 février 2026 : fin de la période de divulgation de 90 jours.

Voici les commentaires de l'équipe de Truffle Security :

Rendre à César ce qui appartient à César

En toute transparence, le triage initial était frustrant ; le rapport a été rejeté comme « comportement intentionnel ». Mais après avoir fourni des preuves concrètes provenant de l'infrastructure même de Google, l'équipe GCP VDP a pris le problème au sérieux.

Elle a élargi son pipeline de détection des fuites d'identifiants pour couvrir les clés que nous avons signalées, protégeant ainsi de manière proactive les clients réels de Google contre les acteurs malveillants qui exploitent leurs clés API Gemini. Elle s'est également engagée à corriger la cause profonde, même si nous n'avons pas encore vu de résultats concrets.

Développer des logiciels à l'échelle de Google est extrêmement difficile, et l'API Gemini a hérité d'une architecture de gestion des clés conçue pour une autre époque. Google a reconnu le problème que nous avons signalé et a pris des mesures significatives. Les questions qui restent en suspens sont de savoir si Google informera ses clients des risques de sécurité associés à leurs clés existantes et si Gemini adoptera finalement une architecture d'authentification différente.

Où Google dit vouloir aller

Google a rendu publique sa feuille de route. Voici ce qu'elle dit :

- Paramètres par défaut limités. Les nouvelles clés créées via AI Studio seront par défaut accessibles uniquement à Gemini, ce qui empêchera toute utilisation involontaire entre services.

- Blocage des clés divulguées. Par défaut, les clés API qui ont été divulguées et utilisées avec l'API Gemini seront bloquées.

- Notification proactive. Google prévoit de communiquer de manière proactive lorsqu'il identifie des clés divulguées, afin de permettre une action immédiate.

Il s'agit là d'améliorations significatives, dont certaines sont clairement déjà en cours. Nous aimerions voir Google aller plus loin et auditer rétroactivement les clés existantes concernées, puis informer les propriétaires de projets qui pourraient être exposés à leur insu, mais honnêtement, cela représente une tâche colossale.

Ce que vous devez faire dès maintenant

Si vous utilisez Google Cloud (ou l'un de ses services tels que Maps, Firebase, YouTube, etc.), la première chose à faire est de déterminer si vous êtes exposé. Voici comment procéder.

Étape 1 : vérifiez chaque projet GCP pour l'API Generative Language.

Accédez à la console GCP, naviguez vers API et services > API et services activés, et recherchez « API Generative Language ». Répétez cette opération pour chaque projet de votre organisation. Si elle n'est pas activée, vous n'êtes pas concerné par ce problème spécifique.

Étape 2 : si l'API Generative Language est activée, vérifiez vos clés API.

Accédez à API et services > Identifiants. Vérifiez la configuration de chaque clé API. Vous recherchez deux types de clés :

- Les clés accompagnées d'une icône d'avertissement, ce qui signifie qu'elles sont définies comme illimitées.
- Les clés qui mentionnent explicitement l'API Generative Language dans leurs services autorisés.

Ces deux configurations permettent à la clé d'accéder à Gemini.

Étape 3 : vérifiez qu'aucune de ces clés n'est publique.

Il s'agit d'une étape cruciale. Si une clé avec accès à Gemini est intégrée dans le JavaScript côté client, enregistrée dans un référentiel public ou exposée d'une autre manière sur Internet, vous avez un problème. Commencez par vos clés les plus anciennes. Ce sont celles qui sont le plus susceptibles d'avoir été déployées publiquement selon l'ancienne recommandation selon laquelle les clés API peuvent être partagées en toute sécurité, puis d'avoir obtenu rétroactivement des privilèges Gemini lorsque quelqu'un de votre équipe a activé l'API.

Si vous trouvez une clé exposée, remplacez-la.

Le modèle découvert (des identifiants publics obtenant discrètement des privilèges sensibles) n'est pas propre à Google. À mesure que de plus en plus d'organisations intègrent des capacités d'IA à leurs plateformes existantes, la surface d'attaque pour les identifiants hérités s'étend d'une manière que personne n'avait prévue.

À propos de Truffle Security

Truffle Security est une entreprise leader dans le domaine de la cybersécurité qui se consacre à la protection des informations sensibles. Basé sur le projet open source TruffleHog™, le logiciel de l'entreprise protège les secrets des développeurs et des machines, tels que les clés privées et les identifiants, analyse les capacités de chaque clé afin de déterminer son impact, et les suit et les gère lorsqu'elles sont exposées à l'aide d'une interface de gestion intuitive. Grâce à cette interface et à des workflows d'authentification sécurisés, Truffle Security prévient les violations en détectant et en classifiant de manière unique plus de 800 identifiants d'identité machine, en validant ceux qui sont actifs, en analysant leur champ d'accès et en escaladant les problèmes pour qu'ils soient corrigés, aidant ainsi les clients à protéger leurs informations critiques.

Source : Rapport de Truffle Security

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Google lance l'API Developer Knowledge et le serveur MCP pour un accès direct à la documentation officielle de Google, offrant aux développeurs et aux outils d'IA un accès lisible par machine

Les API sont devenues la principale surface d'attaque en 2024, l'IA étant le principal facteur de risque pour la sécurité des API avec une augmentation massive de 1025 % des vulnérabilités liées à l'IA

Google affirme qu'une attaque à utilisé plus de 100 000 instructions génératives pour tenter de cloner le chatbot IA Gemini; Une extraction de modèle pour obtenir la logique qui fait fonctionner le modèle

[kain_tn]

C'est quand-même fou ce travail d'amateur!

Plus on en apprend sur ces GAFAM et plus on rigole!

[Stéphane le calme]

Une clé API Gemini volée a transformé une facture de 180 $ en 82 000 $ en deux jours :
quand la doctrine « Shared Responsibility Model » de Google laisse les petits développeurs seuls face à des factures catastrophiques

Une startup mexicaine de trois développeurs se retrouve face à une facture de 82 314 dollars en quarante-huit heures, après le vol d'une clé API Google Cloud. Ce cas spectaculaire n'est pas un fait divers isolé : il révèle une faille structurelle dans la façon dont Google a intégré Gemini à son infrastructure de clés API existante — et soulève des questions fondamentales sur la responsabilité des grands fournisseurs cloud face aux petites équipes qui leur font confiance.

Il a suffi de deux jours. Entre le 11 et le 12 février 2026, une clé API Google Cloud compromise a permis à des attaquants inconnus de générer 82 314,44 dollars de consommation sur les services Gemini d'une jeune pousse mexicaine. La facture mensuelle habituelle de cette équipe de trois développeurs s'élevait à environ 180 dollars. En moins de quarante-huit heures, elle avait été multipliée par 457.

L'un des développeurs affectés a partagé sa détresse sur Reddit avec ces mots : « Je suis en état de choc et de panique en ce moment. » Il y décrit comment la clé API Google Cloud de leur startup a été compromise sur une courte fenêtre de temps, utilisée massivement pour accéder aux services Gemini 3 Pro Image et Gemini 3 Pro Text.

La startup opérait dans des conditions financières serrées, espérant qu'un jour son produit deviendrait rentable. Les développeurs redoutent que même le paiement d'un tiers de cette somme pourrait suffire à mettre la société en faillite. Face à cette situation, ils ont tenté de négocier avec Google, mais le géant technologique a refusé de revoir le montant avant tout paiement. Ils ont également déposé plainte auprès du FBI.

La défense de Google : le modèle de responsabilité partagée

La réponse officielle de Google a été rapide et sans concession. Un porte-parole de Google Mountain View a indiqué que les clients utilisant les services d'IA générative sont responsables de la protection de leurs propres identifiants, dans le cadre du « Shared Responsibility Model » de la plateforme. En vertu de ce modèle, les fournisseurs cloud sécurisent l'infrastructure, mais les utilisateurs doivent sécuriser leurs propres outils d'authentification.

Les développeurs ont déclaré ne pas avoir commis d'erreur opérationnelle « évidente ». Et, selon eux, c'est là tout le problème : la frontière entre une bonne et une mauvaise pratique de sécurité est de plus en plus floue dans l'écosystème cloud, notamment en raison d'une vulnérabilité structurelle que des chercheurs ont mis des mois à faire reconnaître par Google lui-même. Ce positionnement est juridiquement défendable. Il est aussi profondément problématique.

La faille sous-jacente : quand Gemini a silencieusement élargi les privilèges des clés API

Pour comprendre ce qui s'est passé, il faut revenir en arrière. Pendant des années, les clés API Google Cloud — reconnaissables à leur préfixe AIza — ont été conçues comme de simples identifiants de projet pour la facturation. La documentation officielle de Google Maps, par exemple, invitait explicitement les développeurs à intégrer leur clé API directement dans le code HTML de leurs pages web, dans une balise <script> visible dans le code source de n'importe quel navigateur.

La documentation Firebase allait dans le même sens, en affirmant que les clés API pour les services Firebase « ne sont pas secrètes » et qu'elles peuvent « être intégrées en toute sécurité dans le code client ».

Ces instructions étaient exactes au moment de leur rédaction. Les clés n'étaient pas des credentials d'authentification à proprement parler. Puis Gemini est arrivé — et tout a changé, sans que personne ne soit prévenu.

Lorsqu'un développeur active l'API Gemini (officiellement dénommée « Generative Language API ») sur un projet Google Cloud, toutes les clés API existantes de ce projet acquièrent silencieusement la capacité de s'authentifier auprès des endpoints Gemini. La clé elle-même ne change pas. Ce qui change, c'est ce que le backend de Google accepte désormais d'elle.

La firme de cybersécurité TruffleSecurity, à l'origine de cette découverte, résume le problème en une phrase : « Aucun avertissement. Aucune boîte de dialogue de confirmation. Aucune notification par e-mail. »

2 863 clés exposées découvertes dans une seule exploration du web

L'ampleur du problème est vertigineuse. TruffleSecurity a scanné le jeu de données Common Crawl de novembre 2025 — une archive publique couvrant environ 700 téraoctets de contenu web, soit 2,29 milliards de pages — et a identifié 2 863 clés API Google actives et vulnérables à cette escalade de privilèges.

Parmi les victimes potentielles : des institutions financières majeures, des entreprises de sécurité, des cabinets de recrutement mondiaux, et Google lui-même. L'une des clés découvertes était intégrée dans la page source d'un produit public de Google depuis au moins février 2023, confirmé via Internet Archive. Lors des tests, un simple appel à l'endpoint /models de l'API Gemini retournait un code 200 OK avec la liste complète des modèles disponibles.

La surface d'attaque mobile est encore plus vaste. La société Quokka a publié un rapport complémentaire révélant que 39,5 % des applications d'un corpus de 250 000 apps contenaient des clés API Google codées en dur, représentant plus de 35 000 clés uniques. Les APK Android étant décompilables avec des outils open source librement disponibles, extraire une clé ne nécessite qu'une simple expression régulière suivie d'un appel API.

Les deux catégories de vulnérabilités identifiées sont CWE-1188 (initialisation non sécurisée par défaut) et CWE-269 (attribution incorrecte de privilèges). Un développeur créant une clé pour un widget cartographique génère sans le savoir un credential capable d'accéder à des endpoints d'IA sensibles, parce que la configuration par défaut autorise l'accès à toutes les API activées dans le projet — y compris Gemini.

Une divulgation laborieuse : Google a d'abord rejeté le rapport

Le chemin de la découverte à la reconnaissance publique a été semé d'embûches. TruffleSecurity a soumis son rapport au programme de divulgation des vulnérabilités de Google le 21 novembre 2025. Quatre jours plus tard, Google a conclu que le comportement était « intentionnel » et a classé le rapport sans suite.

Les chercheurs ont tenu bon. Le 1^er décembre 2025, après avoir fourni des exemples concrets tirés de l'infrastructure propre de Google — notamment des clés sur des sites web de produits Google — le rapport a gagné en traction en interne. Le lendemain, Google reclassifiait le rapport de « Customer Issue » en « Bug », en rehaussait la sévérité, et demandait la liste complète des 2 863 clés exposées.

Le 13 janvier 2026, Google a formellement classé la vulnérabilité comme une escalade de privilèges inter-services de niveau 1. Le 2 février 2026, la correction de la cause racine était toujours en cours. La fenêtre de divulgation de 90 jours ayant expiré le 19 février, la divulgation publique a suivi le 25-26 février 2026. Entre-temps, Google a déclaré avoir mis en place des mesures proactives pour détecter et bloquer les clés API exposées tentant d'accéder à l'API Gemini. Mais pour l'équipe mexicaine dont la facture s'est envolée à 82 000 dollars, ce correctif est arrivé trop tard.

La vraie question : qui doit protéger les développeurs des excès de facturation ?

Au-delà de la faille technique, cette affaire met en lumière un débat plus profond sur la responsabilité des grands fournisseurs cloud vis-à-vis des petits développeurs.

Les opérateurs de cartes de crédit ont résolu ce problème il y a des décennies avec des systèmes de détection de fraude et des plafonds de responsabilité. Les fournisseurs cloud ont fait le choix de ne pas en faire autant. Un plafond de dépenses strict — qui couperait le service lorsque la facture atteint un seuil défini par l'utilisateur — serait techniquement trivial à mettre en place. La question est de savoir pourquoi aucun d'entre eux ne le propose comme option par défaut.

L'un des développeurs a argumenté que les fournisseurs cloud devraient mettre en place des protections plus robustes contre les anomalies de facturation extrêmes, suggérant que les plateformes devraient automatiquement stopper ou vérifier les charges dès que l'utilisation atteint des seuils anormaux.

La distinction entre une alerte de facturation et un coupe-circuit est fondamentale. Les alertes sont des notifications — elles arrivent après coup, pendant que le compteur tourne. Pour une startup brûlant quelques centaines de dollars par mois, un pic anormal ne sera pas intercepté par une équipe financière. Pour un développeur seul dans un pays où 82 000 dollars représentent une somme qui peut changer une vie, il n'existe aucun filet de sécurité.

Ce que les développeurs doivent faire maintenant

Face à cette vulnérabilité, TruffleSecurity recommande plusieurs mesures immédiates à tout utilisateur de Google Cloud. L'outil open source TruffleHog — fort de plus de 24 800 étoiles sur GitHub — permet de scanner les dépôts de code, les pipelines CI/CD et les assets web à la recherche de clés API Google exposées. Il supporte la vérification active, c'est-à-dire qu'il tente réellement de s'authentifier avec les clés trouvées pour confirmer si elles sont actives.

Il convient également de revoir les restrictions appliquées à chaque clé API dans la console Google Cloud. Une clé destinée à Google Maps n'a aucune raison d'avoir accès à l'API Gemini. La mise en place de restrictions par API et par référent HTTP est une hygiène de base que beaucoup de projets négligent, souvent parce que la documentation officielle a historiquement minimisé les risques associés à ces clés.

Enfin, la rotation régulière des clés API — même en l'absence de compromission connue — reste une bonne pratique. Les clés statiques, intégrées une fois dans un projet et jamais réévaluées, sont un vecteur d'attaque sous-estimé.

Conclusion

L'affaire de la startup mexicaine est le symptôme d'un problème systémique à l'intersection de trois dynamiques : la démocratisation rapide des APIs d'IA générative, une architecture de clés API conçue pour une époque révolue, et un modèle de facturation qui expose les utilisateurs les plus vulnérables à des risques catastrophiques.

Google a reconnu la faille et travaille à la corriger. Mais pour des milliers de développeurs dont les clés sont déjà publiques sur le web — souvent à la suite des instructions de Google lui-même — la menace reste entière. Et la question de savoir qui doit payer quand le système échoue reste, pour l'instant, sans réponse satisfaisante.

Sources : TruffleSecurity, documentation Google, vidéo dans le texte, Shared Responsibility Model, capture d'écran de l'un des développeurs

Et vous ?

Les grands fournisseurs cloud (Google, AWS, Azure) ont-ils une responsabilité morale — ou même légale — lorsqu'une vulnérabilité dans leur propre architecture de sécurité conduit à des pertes financières catastrophiques pour leurs clients ?

Un plafond de dépenses obligatoire et contraignant (qui coupe réellement l'accès plutôt que d'envoyer une alerte) devrait-il être imposé par la réglementation aux fournisseurs cloud, à l'instar des protections dont bénéficient les détenteurs de cartes bancaires ?

La doctrine du « Shared Responsibility Model » est-elle encore pertinente à l'ère de l'IA générative, où la surface d'attaque et les coûts associés à une compromission ont été multipliés par des ordres de grandeur ?

TruffleSecurity a dû montrer à Google des exemples tirés de sa propre infrastructure pour faire reconnaître la vulnérabilité. Que dit cela de l'efficacité des programmes de divulgation responsable chez les grandes plateformes ?

[Fagus]

En même temps, google avait classé ça "not a bug" initialement

"Don't be evil"

[popo]

Le 13 janvier 2026, Google a formellement classé la vulnérabilité comme une escalade de privilèges inter-services de niveau 1. Le 2 février 2026, la correction de la cause racine était toujours en cours. La fenêtre de divulgation de 90 jours ayant expiré le 19 février, la divulgation publique a suivi le 25-26 février 2026. Entre-temps, Google a déclaré avoir mis en place des mesures proactives pour détecter et bloquer les clés API exposées tentant d'accéder à l'API Gemini. Mais pour l'équipe mexicaine dont la facture s'est envolée à 82 000 dollars, ce correctif est arrivé trop tard.

C'est choquant !
Google reconnait qu'ils est en tort mais demande quand même aux devs qui en ont subi les conséquence de payer la facture !

[ericb2]

Comment acquérir facilement une (probablement) bonne idée ...