3 000 clés API Google Cloud exposées donnaient un accès ouvert à Gemini

Près de 3 000 clés Google Cloud API traînent en clair sur le web, et le pire c’est qu’elles peuvent maintenant ouvrir la porte à Gemini. Pas parce que des devs ont fait n’importe quoi hier soir, mais parce qu’un simple « enable » de l’API Generative Language dans un projet peut transformer une clé utilisée pour Maps en sésame pour des endpoints IA plus sensibles.

Le truc, c’est que pendant des années, ces clés « AIza… » ont été traitées comme des identifiants pratiques, pas comme des secrets. Sauf que Gemini les accepte aussi pour s’authentifier. Résultat: des attaquants peuvent aspirer des clés dans le code JavaScript de sites publics, tester ce qui répond côté Gemini, et potentiellement taper dans des fichiers, des contenus en cache, ou faire exploser la facture à coups d’appels LLM.

Pourquoi l’activation de Gemini change la nature d’une clé « AIza »

À la base, une clé Google API, c’est souvent le petit bout de config que tu colles dans une page pour afficher une carte, charger un widget YouTube, brancher de l’Analytics, ou faire tourner un service Firebase. Beaucoup d’équipes l’ont mise côté client, visible dans le code source, parce que l’usage était pensé « public ». Tant que la clé ne donnait accès qu’à des API de ce type, l’impact restait limité, surtout si les quotas étaient bas.

Ce qui coince, c’est le moment où quelqu’un active Gemini dans le même projet Google Cloud. Là, sans changer une ligne sur le site, la même clé peut se mettre à authentifier des appels vers des endpoints Gemini. Des chercheurs ont montré qu’avec une clé exposée, on pouvait au minimum interroger des endpoints comme celui qui liste les modèles disponibles. Et si le projet utilise aussi des fonctions liées aux fichiers ou aux contenus en cache, la surface d’attaque s’élargit vite.

On parle d’une escalade de privilèges « par design » plus que d’une simple fuite classique. La séquence est vicieuse: tu crées une clé pour un usage banal, tu la déploies en front, tu l’oublies, et des mois plus tard un collègue active l’API LLM pour tester Gemini. À ce moment-là, toutes les clés du projet, y compris celles déjà exposées publiquement, héritent potentiellement d’un accès plus large. Sans alerte claire, sans pop-up qui hurle « attention, tu viens de rendre publiques tes clés Gemini ».

Et il y a un détail qui fait mal: la création d’une nouvelle clé dans Google Cloud a longtemps eu un défaut de posture sécurité. Par défaut, la clé peut être « Unrestricted », donc valable pour toutes les API activées dans le projet. Dans un monde pré-Gemini, c’était déjà discutable. Dans un monde où une API IA peut coûter cher et toucher à des données, c’est un cadeau pour les gens qui scannent le web à la recherche de clés « AIza ».

2 863 clés trouvées via Common Crawl, et des secteurs très variés

Le chiffre qui revient, c’est autour de 2 800 à 3 000 clés actives retrouvées en clair sur internet. La méthode est bête comme chou: tu prends un gros instantané du web, comme le dataset Common Crawl de novembre 2025, tu cherches les motifs « AIza », puis tu testes si la clé répond encore. Les chercheurs expliquent avoir identifié 2 863 clés « live », donc pas juste des vieilles chaînes mortes, mais des clés qui peuvent encore servir.

Ce qui est intéressant, c’est la diversité des organisations touchées. Dans le lot, on trouve des sites liés à des institutions financières, des boîtes de recrutement, des entreprises de sécurité, et même des propriétés web associées à Google. Ça ne veut pas dire que tout le monde s’est fait piller, mais ça montre un truc simple: ce n’est pas « le problème des petits devs du dimanche ». Même des équipes structurées ont laissé des clés côté client parce que, pendant longtemps, ce n’était pas considéré comme une fuite critique.

Il y a aussi le parallèle côté mobile qui fait froid dans le dos. Une autre analyse, menée sur un gros échantillon d’applications Android, parle de plus de 35 000 clés uniques retrouvées dans environ 250 000 apps scannées. Là encore, toutes ne donnent pas forcément accès à Gemini, mais ça te donne l’ordre de grandeur: des clés Google, il y en a partout, dans du code distribué à grande échelle, difficile à rappeler et difficile à « réparer » vite.

Ce qui rend l’histoire explosive, c’est l’effet « héritage ». Une clé peut être exposée depuis des années dans un script de site vitrine, et personne n’y touche. Puis un jour, l’équipe produit veut tester un chatbot interne, active l’API Generative Language dans le projet existant « parce que c’est pratique », et sans s’en rendre compte, elle vient de donner une nouvelle valeur à une clé déjà publique. Du coup, l’exposition n’est pas nouvelle, mais le risque, lui, vient de grimper d’un étage.

Le scénario d’attaque: scraping, endpoints Gemini, puis la facture qui s’emballe

Concrètement, un attaquant n’a pas besoin d’être un génie. Il peut scraper des sites publics, récupérer des clés « AIza » dans le JavaScript, puis automatiser des tests sur les endpoints Gemini. Une démonstration citée par les chercheurs consiste à appeler un endpoint de type « models » pour voir ce qui est accessible. C’est le premier pas: valider que la clé n’est pas juste décorative, mais qu’elle ouvre une porte réelle sur l’API IA du projet.

Ensuite, tu as le volet « données ». Les chercheurs expliquent qu’avec une clé valide, un attaquant peut potentiellement accéder à des fichiers uploadés, à des données mises en cache, et plus largement à des endpoints sensibles exposés par le projet. Tout dépend de ce qui est activé et de la manière dont le projet est configuré, mais le point clé est là: on n’est plus seulement sur « quelqu’un affiche une carte Google sur mon site ». On parle d’accès à des ressources qui peuvent être internes à une organisation.

Le deuxième volet, c’est le fric. Les appels LLM coûtent de l’argent, et l’abus peut aller vite. Des spécialistes citent un scénario où, selon le modèle et la taille du contexte, un acteur malveillant qui maxe les quotas peut générer des milliers de dollars de charges par jour sur un seul compte victime. Même si tu as des limites, un bot peut tourner non-stop, et toi tu découvres le carnage quand la facture tombe ou quand les quotas sont épuisés et que ton service s’écroule.

Le truc le plus perfide, c’est que l’attaque peut rester « silencieuse » au début. Un fraudeur peut tester doucement, puis monter en charge. Et si ton monitoring n’est pas calé sur des patterns IA (pics d’appels, prompts répétitifs, géolocalisation bizarre, user-agents automatisés), tu peux passer à côté. Marc, un RSSI que j’ai eu au téléphone il y a quelques mois sur un incident similaire, me disait: « la fraude API, ça se voit quand c’est trop tard, parce que tout ressemble à du trafic normal… jusqu’au moment où tu regardes la ligne budgétaire ».

Google réagit: blocage des clés fuitées et restrictions sur les nouvelles

Côté Google, la réponse officielle tient en deux axes: couper l’accès Gemini aux clés connues comme fuitées, et durcir la création de nouvelles clés pour éviter le grand n’importe quoi « unrestricted ». Google dit avoir mis en place des mesures proactives pour détecter et bloquer les clés exposées qui tentent d’accéder à l’API Gemini. Et ça, c’est déjà une bonne nouvelle, parce que ça réduit le risque immédiat pour des victimes qui n’ont même pas compris qu’elles étaient concernées.

Il y a aussi un changement annoncé sur les clés créées via l’environnement orienté IA: les nouvelles clés liées à AI Studio doivent par défaut être limitées au périmètre Gemini. En clair, on essaie d’éviter qu’une clé créée pour un usage IA se mette à fonctionner partout, ou qu’une clé créée pour un usage « public » se retrouve valable pour l’IA juste parce que l’API est activée dans le projet. C’est du bon sens, mais ça arrive après coup, une fois que des milliers de clés sont déjà dehors.

Le dossier a aussi bougé en interne: la vulnérabilité a été requalifiée, avec une sévérité revue à la hausse, et un classement qui ressemble à « privilege escalation » sur un service. Une chronologie publique indique que Google a demandé la liste des clés exposées, a partagé un plan de remédiation, et continue de travailler sur un correctif de fond. Dit autrement: ce n’est pas juste un « mauvais usage client », c’est un problème d’architecture et de défauts par défaut.

Ma nuance, parce qu’il en faut une: bloquer des clés connues, c’est utile, mais ça ne règle pas tout. Les clés peuvent réapparaître, être copiées ailleurs, ou ne pas être détectées tout de suite. Et surtout, si le modèle mental des devs ne change pas, on rejouera la même scène au prochain service « sensible » qui décidera d’accepter le même format de clé. Le vrai nerf de la guerre, c’est de rendre impossible, ou au moins très difficile, qu’une clé exposée côté client devienne un jeton d’authentification vers des données privées.

Ce que les devs doivent faire lundi matin: audit, rotation, restrictions

Si tu gères un projet Google Cloud, la première question est brutale: est-ce que l’API Generative Language (Gemini) est activée sur un projet qui contient des clés utilisées côté client? Beaucoup d’équipes ont un « projet fourre-tout » où cohabitent Maps, Analytics, un bout de Firebase, et maintenant un test Gemini. C’est pratique, mais c’est exactement la configuration qui transforme une vieille clé publique en problème de sécurité.

Deuxième étape: inventaire et audit des clés. Tu listes toutes les clés API du projet, tu identifies lesquelles sont utilisées dans du code public (site web, appli mobile, SDK distribué), et tu regardes leurs restrictions. Si une clé est « Unrestricted », tu la considères comme suspecte par défaut. Tu limites par API, par referrer HTTP (pour les usages web), par application, et tu mets des quotas réalistes. Oui, ça casse parfois des intégrations, mais c’est le prix à payer.

Troisième étape: rotation. Les recommandations sont claires: si une clé est exposée publiquement, tu la remplaces. Pas demain, pas « quand on aura le temps ». Tu crées une nouvelle clé restreinte, tu déploies, tu révoques l’ancienne. Et tu surveilles les erreurs, parce que la rotation, dans la vraie vie, ça révèle toujours un vieux microservice oublié ou un script planqué dans un CMS. Le but, c’est de ne pas laisser une fenêtre de tir de plusieurs semaines.

Dernier point, plus organisationnel: tu sépares les projets et tu sépares les usages. Une clé destinée à un widget public ne devrait jamais vivre dans le même univers qu’une API IA qui peut accéder à des fichiers ou générer des coûts élevés. Tu mets aussi des alertes de facturation et des alertes de quotas spécifiques à l’IA, parce que les patterns d’abus ne ressemblent pas à ceux d’une API Maps. Et si tu penses que « personne ne va trouver ma clé dans mon JS », rappelle-toi qu’il suffit d’un scan automatisé sur Common Crawl pour en déterrer des milliers.