- 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
Aucun commentaire pour le moment.