Les clés API Google n'étaient pas secrètes, mais Gemini a changé les règles car il utilise les mêmes clés pour accéder à vos données

Un pirate peut accéder à vos données et vous facturer l'utilisation du LLM

Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte.

Gemini, anciennement Bard, est un assistant conversationnel développé par l'entreprise Google. Pour générer du texte, il se base sur une famille de grands modèles de langage également appelée Gemini, introduite au public le 7 décembre 2023. Gemini est l'acronyme de Generalized Multimodal Intelligence Network. Gemini peut comprendre et interagir avec l'audio et la vidéo, et générer du texte (poésie, scripts, pièces musicales, courriels, lettres, etc.), du code, des traductions (entre plus de 100 langues). Il peut produire plusieurs types de contenu créatif (images, dessins, sons, musique, vidéos…), aider des chercheurs en analysant des données ou en générant des hypothèses.

Pendant plus de dix ans, Google a répété aux développeurs que les clés API Google (comme celles utilisées dans Maps, Firebase, etc.) n'étaient pas secrètes. Mais ce n'est plus vrai : Gemini accepte les mêmes clés pour accéder à vos données privées. Truffle Security a analysé des millions de sites web et trouvé près de 3 000 clés API Google, initialement déployées pour des services publics tels que Google Maps, qui authentifient désormais également Gemini, même si elles n'étaient pas destinées à cet usage. Avec une clé valide, un pirate peut accéder aux fichiers téléchargés, aux données mises en cache et facturer l'utilisation du LLM à votre compte. Même Google disposait d'anciennes clés API publiques, qu'il considérait comme non sensibles, mais qui pouvait être utiliser pour accéder au Gemini interne de Google.


Le problème fondamental

Google Cloud utilise un seul format de clé API (AIza...) à deux fins fondamentalement différentes : l'identification publique et l'authentification sensible.

Pendant des années, Google a explicitement indiqué aux développeurs que les clés API pouvaient être intégrées en toute sécurité dans le code côté client. La liste de contrôle de sécurité de Firebase stipule que les clés API ne sont pas des secrets.

Remarque : celles-ci sont très différentes des clés JSON de compte de service utilisées pour alimenter GCP.


La documentation JavaScript de Google Maps invite les développeurs à coller leur clé directement dans le code HTML.


Cela semble logique. Ces clés ont été conçues comme des identifiants de projet à des fins de facturation et peuvent être soumises à des restrictions supplémentaires (contournables) telles que la liste blanche des référents HTTP. Elles n'ont pas été conçues comme des identifiants d'authentification.

Puis Gemini est arrivé.


Lorsque vous activez l'API Gemini (Generative Language API) sur un projet Google Cloud, les clés API existantes dans ce projet (y compris celles qui se trouvent dans le JavaScript public de votre site web) peuvent accéder silencieusement aux points de terminaison sensibles de Gemini. Sans avertissement. Sans boîte de dialogue de confirmation. Sans notification par e-mail.

Cela crée deux problèmes distincts :

Extension rétroactive des privilèges. Vous avez créé une clé Maps il y a trois ans et l'avez intégrée dans le code source de votre site web, exactement comme Google vous l'avait demandé. Le mois dernier, un développeur de votre équipe a activé l'API Gemini pour un prototype interne. Votre clé Maps publique est désormais un identifiant Gemini. Toute personne qui la récupère peut accéder à vos fichiers téléchargés, à votre contenu mis en cache et faire grimper votre facture d'IA. Personne ne vous en a informé.

Paramètres par défaut non sécurisés. Lorsque vous créez une nouvelle clé API dans Google Cloud, elle est par défaut « sans restriction », ce qui signifie qu'elle est immédiatement valable pour toutes les API activées dans le projet, y compris Gemini. L'interface utilisateur affiche un avertissement concernant « l'utilisation non autorisée », mais l'architecture par défaut est largement ouverte.


Résultat : des milliers de clés API qui ont été déployées comme des jetons de facturation inoffensifs sont désormais des identifiants Gemini actifs sur l'internet public.

Ce qui fait de cela une élévation de privilèges plutôt qu'une mauvaise configuration, c'est la séquence des événements.

1. Un développeur crée une clé API et l'intègre dans un site web pour Maps. (À ce stade, la clé est inoffensive.)

2. L'API Gemini est activée sur le même projet. (Désormais, cette même clé peut accéder à des points de terminaison Gemini sensibles.)

3. Le développeur n'est jamais averti que les privilèges de la clé ont changé en arrière-plan. (La clé est passée d'un identifiant public à un identifiant secret).

Bien que les utilisateurs puissent restreindre les clés API Google (par service API et application), la vulnérabilité réside dans la posture par défaut non sécurisée (CWE-1188) et l'attribution incorrecte des privilèges (CWE-269) :

- Mise à niveau implicite de la confiance : Google a appliqué rétroactivement des privilèges sensibles à des clés existantes qui étaient déjà légitimement déployées dans des environnements publics (par exemple, des bundles JavaScript).

- Absence de séparation des clés : une conception sécurisée de l'API nécessite des clés distinctes pour chaque environnement (clés publiables vs clés secrètes). En s'appuyant sur un format de clé unique pour les deux, le système s'expose à des compromissions et à la confusion.

Échec des paramètres par défaut sécurisés : l'état par défaut d'une clé générée via le panneau API GCP permet d'accéder à l'API Gemini sensible (en supposant qu'elle soit activée). Un utilisateur qui crée une clé pour un widget de carte génère sans le savoir un identifiant capable d'effectuer des actions administratives.

Ce qu'un pirate peut faire

L'attaque est très simple. Un pirate visite votre site web, consulte le code source de la page et copie votre clé AIza... à partir de l'intégration Maps. Il exécute ensuite :



Au lieu d'un message d'erreur 403 Forbidden, il obtient un message 200 OK. À partir de là, le pirate peut :

- Accéder à des données privées. Les points de terminaison /files/ et /cachedContents/ peuvent contenir des ensembles de données téléchargés, des documents et du contenu mis en cache. Tout ce que le propriétaire du projet a stocké via l'API Gemini est accessible.

- Faire grimper votre facture. L'utilisation de l'API Gemini n'est pas gratuite. En fonction du modèle et de la fenêtre contextuelle, un acteur malveillant qui maximise les appels API pourrait générer des milliers de dollars de frais par jour sur un seul compte victime.

Épuiser vos quotas. Cela pourrait entraîner l'arrêt complet de vos services Gemini légitimes.

Le pirate ne touche jamais à votre infrastructure. Il se contente de récupérer une clé sur une page web publique.

2 863 clés actives sur l'Internet public

Pour comprendre l'ampleur du problème, Truffle Security a analysé l'ensemble de données Common Crawl de novembre 2025, une archive massive (~700 TiB) de pages web publiques contenant du code HTML, JavaScript et CSS provenant de l'ensemble de l'Internet. Ils ont identifié 2 863 clés API Google actives vulnérables à ce vecteur d'escalade de privilèges.


Il ne s'agit pas seulement de projets parallèles menés par des amateurs. Parmi les victimes figuraient de grandes institutions financières, des sociétés de sécurité, des cabinets de recrutement internationaux et, notamment, Google lui-même. Si les équipes d'ingénieurs du fournisseur ne parviennent pas à éviter ce piège, il est irréaliste d'attendre de chaque développeur qu'il le contourne correctement.

Preuve de concept : les propres clés de Google

Les chercheurs ont fourni à Google des exemples concrets tirés de sa propre infrastructure pour illustrer le problème. L'une des clés testées était intégrée dans le code source d'une page du site web public d'un produit Google. En consultant les archives Internet, ils ont confirmé que cette clé était accessible au public depuis au moins février 2023, bien avant l'existence de l'API Gemini. La page ne comportait aucune logique côté client tentant d'accéder à des points de terminaison Gen AI. Elle était uniquement utilisée comme identifiant de projet public, ce qui est la norme pour les services Google.


Ils ont testé la clé en accédant au point de terminaison /models de l'API Gemini (dont Google a confirmé qu'il était concerné) et avons obtenu une réponse 200 OK répertoriant les modèles disponibles. Une clé déployée il y a des années à des fins tout à fait bénignes avait silencieusement obtenu un accès complet à une API sensible sans aucune intervention des développeurs.

Chronologie de la divulgation

Truffle Security a signalé ce problème à Google via son programme de divulgation des vulnérabilités le 21 novembre 2025.

- 21 novembre 2025 : ils ont soumis le rapport au VDP de Google.

- 25 novembre 2025 : Google a initialement déterminé que ce comportement était intentionnel. Ils ont contesté cette décision.

- 1er décembre 2025 : après avoir fourni des exemples tirés de la propre infrastructure de Google (y compris des clés sur les sites web des produits Google), le problème a suscité l'intérêt en interne.

- 2 décembre 2025 : Google a reclassé le rapport de « Problème client » à « Bug », a augmenté son niveau de gravité et a confirmé que l'équipe produit évaluait une solution. Ils ont demandé la liste complète des 2 863 clés exposées.

- 12 décembre 2025 : Google a communiqué son plan de remédiation. L'entreprise a confirmé la mise en place d'un pipeline interne pour détecter les clés divulguées, a commencé à restreindre l'accès des clés exposées à l'API Gemini et s'est engagée à traiter la cause profonde avant notre date de divulgation.

- 13 janvier 2026 : Google a classé la vulnérabilité comme « Escalade des privilèges d'un seul service, LECTURE » (niveau 1).

- 2 février 2026 : Google a confirmé que l'équipe travaillait toujours à la résolution de la cause profonde.

- 19 février 2026 : fin de la période de divulgation de 90 jours.

Voici les commentaires de l'équipe de Truffle Security :...