- Google expliquait depuis plus de 10 ans que les clés API ne sont pas secrètes et peuvent être exposées sans risque, mais l’activation de l’API Gemini a transformé cette même clé en moyen d’authentification sensible
- D’anciennes clés publiques utilisées pour Google Maps, Firebase, etc. ont automatiquement obtenu des droits d’accès à l’API Gemini, rendant possible, avec une clé exposée, l’accès à des données privées et la facturation d’utilisation
- Truffle Security a confirmé que 2 863 clés API Google réellement utilisées étaient exposées sur Internet, dont certaines étaient des clés de services appartenant à Google lui-même
- Google a reconnu le problème et met en place le blocage des clés divulguées, des paramètres par défaut dédiés à Gemini et des fonctions d’alerte en cas d’exposition, mais l’examen rétroactif des clés existantes n’est pas encore terminé
- Ce cas montre le risque d’extension des privilèges d’identifiants existants provoquée par l’intégration de fonctions d’IA, et les développeurs doivent vérifier immédiatement si l’API Gemini est activée et si des clés sont exposées
Problème central
- Google Cloud utilise une structure de clé API unique au format
AIza..., qui remplit à la fois le rôle d’identifiant public et celui de moyen d’authentification sensible
- Par le passé, Google indiquait explicitement aux développeurs qu’il était sans danger d’inclure directement une clé API dans le code client
- La checklist de sécurité de Firebase précisait également que « les clés API ne sont pas secrètes »
- Mais lorsqu’une API Gemini est activée, toutes les clés API du projet existant obtiennent automatiquement un droit d’accès aux endpoints Gemini
- Cette extension de privilèges se produit sans avertissement, sans confirmation et sans notification par e-mail
- Cela entraîne deux problèmes
- Extension rétroactive des privilèges (Retroactive Privilege Expansion) : d’anciennes clés Maps publiques deviennent des identifiants d’accès à Gemini
- Paramètres par défaut non sûrs (Insecure Defaults) : lors de la création d’une nouvelle clé, le réglage par défaut est
Unrestricted, ce qui autorise l’accès à toutes les API, Gemini inclus
- Résultat : des milliers de tokens de facturation se sont retrouvés exposés sur Internet après avoir été transformés en véritables identifiants d’authentification
Scénarios d’attaque possibles
- Un attaquant peut copier une clé
AIza... depuis le code source d’un site web et accéder à l’API Gemini avec une simple requête curl
- Un attaquant peut ainsi
- accéder à des données non publiques (endpoints
/files/ et /cachedContents/)
- imputer des frais d’utilisation de l’API Gemini
- épuiser le quota et provoquer une interruption de service
- L’attaque peut être menée sans compromettre l’infrastructure de la victime, simplement en extrayant la clé d’une page web publique
Ampleur des clés exposées
- Truffle Security a analysé le dataset de novembre 2025 de Common Crawl (environ 700 TiB) et trouvé 2 863 clés API Google actives
- Ces clés étaient à l’origine utilisées pour des services publics comme Google Maps, mais disposaient aussi d’un accès à l’API Gemini
- Les victimes potentielles incluent des institutions financières, des entreprises de sécurité, un groupe mondial du recrutement et Google lui-même
- Même Google était exposé au même risque structurel
Cas de clés internes à Google
- Truffle Security a démontré l’accès à l’API Gemini à l’aide de clés présentes dans le code source public de sites produits de Google
- Ces clés étaient publiques depuis avant février 2023 et servaient à l’origine uniquement à identifier un projet
- Un appel à l’endpoint
/models a renvoyé une réponse valide (200 OK), confirmant la possibilité d’accès à une API sensible
- Autrement dit, des clés autrefois inoffensives ont acquis des privilèges sensibles sans intervention des développeurs
Chronologie du signalement et de la réponse
- 21 novembre 2025 : signalement au Google VDP
- 25 novembre : Google estime d’abord qu’il s’agit d’un « comportement prévu »
- 1er–2 décembre : après que Truffle Security a présenté le cas de clés internes à Google, Google reclasse le problème comme bug et relève sa gravité
- 12 décembre : Google commence à étendre son pipeline de détection des clés divulguées et à restreindre l’accès à Gemini
- 13 janvier 2026 : Google classe la faille comme « Single-Service Privilege Escalation (READ) »
- 2 février : confirmation que les travaux de correction de la cause profonde sont en cours
Mesures prises par Google
- Google a annoncé dans sa documentation officielle les mesures de renforcement de sécurité suivantes
- Scoped defaults : les nouvelles clés créées dans AI Studio n’autorisent par défaut que l’accès à Gemini
- Leaked key blocking : blocage automatique de l’accès à l’API Gemini pour les clés divulguées
- Proactive notification : envoi immédiat d’une alerte à l’utilisateur lorsqu’une clé exposée est détectée
- Certaines améliorations sont déjà en cours de déploiement, mais la vérification rétroactive des clés déjà exposées et l’information des utilisateurs ne sont pas encore finalisées
Guide de vérification pour les développeurs
- Étape 1 : vérifier dans tous les projets GCP si la Generative Language API est activée
- Étape 2 : si elle est activée, identifier dans les paramètres des clés API les clés en
Unrestricted ou celles qui incluent Gemini
- Étape 3 : vérifier si ces clés apparaissent dans du code public ou sur des pages web
- Toute clé exposée doit être rotée immédiatement
- Bonus : l’outil TruffleHog permet de détecter automatiquement les clés réellement utilisées qui peuvent accéder à Gemini
- Exemple de commande :
trufflehog filesystem /path/to/your/code --only-verified
Conclusion
- Ce cas illustre un risque structurel où l’ajout de fonctions d’IA donne à d’anciens identifiants publics des privilèges sensibles
- Google a reconnu le problème et agit, mais l’importance de paramètres par défaut sûrs et d’une séparation claire des clés ressort une nouvelle fois
- Les développeurs et les entreprises doivent vérifier immédiatement l’activation de l’API Gemini et l’état d’exposition de leurs clés
1 commentaires
Commentaires sur Hacker News
La documentation de Google AI Studio recommande de déployer des applications via un proxy ouvert
Cette approche donne l’illusion que la clé API est en sécurité puisqu’elle se trouve derrière un proxy, mais en réalité elle permet des abus de facturation IA
Même des applications sans aucune fonctionnalité IA se retrouvent exposées à des modèles coûteux si le périmètre de la clé n’est pas limité manuellement
On peut retrouver facilement ces applications vulnérables rien qu’avec des recherches sur Google, Twitter ou Hacker News
L’analyse associée est résumée dans cet article
Google affirme bloquer les clés divulguées, mais à l’origine ces clés n’étaient pas traitées comme des secrets
L’idéal aurait été d’empêcher toutes les clés créées avant le lancement de Gemini d’accéder à Gemini
Si le système de détection de fuite produit des faux positifs, il risque aussi de bloquer des clés Gemini légitimes
Il faudrait au minimum retirer les autorisations de la Generative Language API de toutes les anciennes clés, mais même cela ne serait pas une solution complète
Au final, il faudra peut-être supprimer en masse cette autorisation de toutes les clés
Cela casserait d’innombrables applications, ce qui explique pourquoi Google hésite à reconnaître le problème
Plus grave encore, les clés exposent aussi les contextes mis en cache et les données téléversées
Il a été découvert que des clés Google codées en dur dans d’anciennes images Android pouvaient réellement être utilisées avec Gemini
Certaines étaient déjà utilisées par beaucoup de monde et se heurtaient donc à des limitations de débit, mais quelques-unes fonctionnaient encore
Il y a environ deux mois, ces clés ont été considérées comme divulguées et toutes ont été désactivées
Les clés créées il y a longtemps étaient à l’origine destinées à des services limités comme Firebase ou Firestore
Mais après le lancement de Gemini, l’accès à Gemini a été activé automatiquement aussi sur les anciennes clés, rendant les abus faciles
Autrement dit, une clé publique incluse dans un fichier APK est devenue telle quelle une clé d’accès à Gemini
Par exemple, si le développeur X crée une clé pour Maps et qu’un autre développeur Y active Gemini dans le même projet,
la clé de X obtient alors des droits d’accès à Gemini
Il faut donc éviter de réutiliser les projets et utiliser des projets GCP séparés selon les services
On peut se demander pourquoi une faille de sécurité aussi évidente n’a pas été détectée plus tôt
Dans une grande entreprise comme Google, il devrait pourtant y avoir des tests ou des spécifications standardisés
Plus une organisation grandit et se complexifie, plus ces angles morts de supervision ont tendance à se multiplier
mais ils restent obsédés par les problèmes d’inversion d’arbre binaire
Cette affaire rappelle les anciens cas d’abus du SSN (numéro de sécurité sociale)
À l’origine, ce n’était qu’un numéro d’identification, mais les problèmes ont explosé lorsqu’il a commencé à être utilisé comme clé d’authentification
C’est une logique où l’on implémente rapidement et à bas coût, avant d’en faire finalement payer le prix aux utilisateurs
Il semble que Google n’ait toujours pas complètement résolu ce problème
C’est une erreur majeure née de la précipitation à lancer Gemini,
et corriger le problème impliquerait probablement de désactiver des clés existantes, avec un fort risque de casser les workflows des clients
Pour Google aussi, c’est une atteinte d’image très grave
Il s’agit d’un problème de rétro-extension des privilèges (Retroactive Privilege Expansion)
Une ancienne clé Maps avait été rendue publique sur un site web, puis lorsqu’un autre développeur de l’équipe active Gemini,
cette clé publique devient immédiatement un identifiant d’accès à Gemini
Au final, n’importe qui peut utiliser cette clé pour accéder à des fichiers téléversés ou à des données en cache
Les utilisateurs qui ont utilisé des clés publiques conformément à l’ancienne documentation en subissent aujourd’hui les conséquences
Un attaquant peut la voler et provoquer une explosion de facturation
Pour l’expliquer simplement, des milliers de clés API existantes sont soudain passées du statut de simples jetons de facturation
à celui d’identifiants d’accès à Gemini
Une clé API Maps était initialement conçue pour fournir un service de cartographie aux utilisateurs tout en facturant ma carte
Le problème, c’est que ces clés peuvent désormais aussi accéder à Gemini
Il aurait fallu créer des projets internes distincts pour isoler les clés,
mais, à force de vouloir déployer vite, on utilise tel quel du code généré par LLM, puis quand les problèmes arrivent, on blâme Google
Les recherches précédentes de l’entreprise de sécurité qui a analysé ce problème étaient elles aussi impressionnantes
Par exemple, leur article « Anyone can Access Deleted and Private Repository Data on GitHub »
révélait une faille permettant d’accéder à des données de dépôts GitHub supprimés
Cette fois encore, leur analyse a été d’une grande aide