2 863 clés API Google, tranquillement exposées dans le code source de sites web, viennent de se muer en brèches de sécurité. Pas à cause d’un piratage, pas à cause d’une erreur de développeur. À cause d’une décision d’architecture chez Google.
Le problème, en deux mots
Pendant plus de dix ans, Google a répété aux développeurs que leurs clés API (format AIza…) n’étaient pas des secrets. Firebase l’écrit noir sur blanc dans sa documentation : « Les clés API ne sont pas des secrets. » La doc Google Maps encourage même à les coller directement dans le HTML. Logique : ces clés servaient juste d’identifiants de facturation pour des services publics. Rien de sensible.
Et puis Gemini est arrivé.
Quand activer une API change tout, en silence
Truffle Security, la société spécialisée dans la détection de secrets exposés, a découvert le pot aux roses. Quand un développeur active l’API Gemini (Generative Language API) sur un projet Google Cloud, toutes les clés API du projet, y compris celles qui traînent depuis trois ans dans le JavaScript d’un site web, gagnent automatiquement l’accès aux points d’entrée Gemini. Pas d’alerte. Pas de pop-up de confirmation. Pas de mail.
Résultat : une clé créée pour afficher une carte Google Maps devient, du jour au lendemain, un sésame pour interroger Gemini, accéder aux fichiers privés stockés via l’API et faire exploser la facture du compte.
2 863 clés vulnérables repérées dans la nature
L’équipe de Truffle Security a scanné le jeu de données Common Crawl de novembre 2025 (environ 700 téraoctets de pages web archivées) et identifié 2 863 clés Google actives et vulnérables. On ne parle pas de projets amateurs : des institutions financières, des sociétés de cybersécurité, des cabinets de recrutement internationaux figurent dans la liste. Mieux (ou pire) : des clés appartenant à Google elles-mêmes, déployées depuis février 2023 sur des sites produits de la firme, donnaient accès à Gemini en interne.
Un attaquant n’a qu’à visiter un site, ouvrir le code source, copier la clé AIza… et lancer une requête vers l’API Gemini. Au lieu d’un refus 403, il obtient un joli 200 OK.
Google a d’abord répondu « c’est normal »
Truffle Security a signalé la faille à Google le 21 novembre 2025. Quatre jours plus tard, la réponse tombe : « comportement prévu ». L’équipe a insisté, preuves à l’appui, en montrant les propres clés de Google vulnérables. Le ton a changé. Début décembre, le rapport est passé de « problème client » à « bug », avec un niveau de sévérité relevé, rapporte The Register. Google a demandé la liste complète des 2 863 clés et lancé un plan de correction.
Mi-janvier 2026, la vulnérabilité a été classée « escalade de privilèges mono-service, lecture » (Tier 1). Mais au 19 février, date de fin de la fenêtre de divulgation de 90 jours, le correctif de fond n’avait toujours pas été déployé, selon Ars Technica.
Ce que Google promet
La feuille de route publiée par Google prévoit trois mesures : les nouvelles clés créées via AI Studio seront restreintes à Gemini par défaut, les clés détectées comme fuitées seront bloquées automatiquement, et des notifications proactives seront envoyées aux propriétaires de projets concernés. Des avancées réelles, mais qui ne règlent pas le problème des milliers de clés anciennes déjà dans la nature.
La communauté développeur sur Hacker News pose une question plus large : comment Google peut-il qualifier des clés de « fuitées » alors qu’il a passé dix ans à dire qu’elles n’avaient rien de confidentiel ?
Et maintenant ?
Si vous utilisez Google Cloud, Firebase ou Maps, vérifiez si l’API Generative Language est activée sur vos projets. Si oui, auditez chaque clé API : celles marquées « non restreintes » ou listant explicitement cette API sont potentiellement exposées. Commencez par les plus anciennes. Ce sont elles qui ont le plus de chances de traîner quelque part sur le web public.
