Depuis plus de dix ans, Google a encouragé les développeurs à considérer les clés d’API comme des éléments non sensibles, notamment pour des services comme Maps ou Firebase. Ces clés, utilisées principalement à des fins de facturation et de suivi d’usage, étaient censées être sécurisées par des restrictions comme les listes blanches d’URL de référent (HTTP referer), mais non pas protégées comme des secrets d’authentification. Cette approche a été largement adoptée, avec des documents officiels de Google affirmant que les clés API n’étaient pas des secrets. Cependant, l’arrivée de Gemini a profondément changé la donne. Lorsqu’un développeur active l’API Gemini (API de langage génératif) dans un projet Google Cloud, toutes les clés API existantes dans ce projet – y compris celles exposées publiquement dans le code client de sites web – acquièrent silencieusement un accès aux fonctionnalités sensibles de Gemini. Aucune alerte, aucune confirmation, aucun message d’avertissement. Ce phénomène, appelé « expansion rétroactive des privilèges », transforme une clé innocente en credential d’accès à des données privées, fichiers téléchargés, contenu mis en cache, voire en outil pour consommer des ressources d’IA à vos frais. Le problème réside dans une architecture inadéquate : une même clé (format AIza...) est utilisée à la fois comme identifiant public (pour Maps) et comme authentification sensible (pour Gemini). Par défaut, les nouvelles clés sont « non restreintes », ce qui signifie qu’elles peuvent accéder à toutes les API activées dans le projet. Ce comportement, classé comme « mauvaise configuration par défaut » (CWE-1188) et « attribution incorrecte des privilèges » (CWE-269), crée un risque majeur. Une analyse effectuée sur le dataset Common Crawl de novembre 2025 a révélé 2 863 clés Google API exposées publiquement, initialement destinées à Maps, mais désormais capables d’accéder à Gemini. Ces clés ont été trouvées sur des sites de grandes institutions financières, de sociétés de cybersécurité, de recrutement international, et même sur des sites web de Google lui-même. Un exemple frappant : une clé publiée depuis février 2023 sur un site public de Google, jamais utilisée pour une API IA, a permis d’obtenir une réponse 200 OK sur l’endpoint /models de Gemini, démontrant qu’elle avait acquis un accès illimité. Le rapport a été soumis à Google le 21 novembre 2025. Initialement traité comme un comportement « attendu », il a été réévalué après la fourniture de preuves tirées de l’infrastructure de Google. Le 2 décembre, Google a reconnu le problème comme un bug critique (Tier 1), a mis en place un pipeline de détection des clés exposées, et a commencé à restreindre l’accès des clés publiques à Gemini. Un correctif à la racine du problème était en cours de développement au moment de la publication. En réponse, les organisations doivent agir immédiatement : vérifier si l’API Generative Language est activée dans leurs projets GCP, auditer toutes les clés API pour s’assurer qu’aucune n’est exposée publiquement, et les renouveler si nécessaire. Outils comme TruffleHog permettent de scanner automatiquement les clés exposées et de confirmer leur accessibilité à Gemini. Ce cas illustre un risque croissant dans l’ère de l’IA : l’ajout de fonctionnalités avancées à des architectures existantes peut transformer des éléments non sensibles en vecteurs d’attaque. Google a reconnu le problème, mais la question reste ouverte : informera-t-il ses clients des clés exposées ? Et adoptera-t-il une architecture d’authentification distincte pour les services sensibles ?