Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Et si votre clé API Google finançait l'IA de quelqu'un d'autre ?

By John D'EliaMay 11, 20265 min read

Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.

En résumé

  • Générer du contenu avec l'API Gemini grâce à des clés API mal configurées est devenu monnaie courante. Lisez la suite avant d'en faire les frais.
  • Nous publions un outil de scan open source gratuit pour identifier les clés API problématiques, à découvrir ici : https://github.com/doitintl/gcp-apikey-check

Ce qui se passe

Chez DoiT, le cloud n'a plus beaucoup de secrets pour nous. Ces derniers temps, la communauté multiplie les témoignages de mauvaises surprises sur la facture Gemini. Que l'utilisateur ait ou non intégré Gemini dans ses applications, il se réveille avec une facture salée liée à la génération de contenu — souvent des images ou des vidéos, qui font grimper l'addition plus vite que les alertes de facturation ne peuvent vous atteindre. Si vous utilisez des clés API Google quelque part, lisez la suite : vos clés sont peut-être à risque.


Comment cela arrive

Google Cloud, comme tous les autres fournisseurs cloud, fonctionne sur un modèle de responsabilité partagée : Google répond de l'infrastructure sous-jacente, les utilisateurs répondent de la sécurité de leur usage de cette infrastructure. Or Google utilise un même format de clé API (AIza...) pour deux usages très différents : identifiants publics de projet et identifiants d'authentification sensibles.

Les clés API Google Maps et Firebase posent problème depuis un moment : par défaut, lors de la génération, aucune restriction n'était appliquée sur l'API — il revenait au développeur de cadrer les API et de les limiter à des sites web, des adresses IP ou des SDK précis ; ce qui n'était pas toujours fait. Pour Maps et Firebase, ces clés se retrouvent souvent dans le code frontend côté client : elles ne sont donc pas particulièrement privées et servent davantage d'identifiants de facturation.

Les ennuis ont commencé dès que l'API Gemini s'est retrouvée activée dans un projet contenant aussi une clé Maps ou Firebase non restreinte. Une fois ces clés découvertes, les acteurs malveillants ont vite appris à en tirer parti.

Lorsque l'API Gemini est activée sur un projet Google Cloud, toute clé API existante non limitée à des API spécifiques dans ce projet peut silencieusement accéder aux endpoints Gemini. Aucun avertissement. Aucun e-mail. Aucune confirmation. Une clé Maps intégrée à votre site il y a des années peut désormais faire office d'identifiant Gemini actif, exposé dans le code source de votre page à la vue de tous.

Autre vecteur de fuite : l'envoi accidentel de clés API ou de clés statiques de Service Account dans des dépôts GitHub publics. Autrefois, ces clés étaient rapidement détournées pour lancer du minage de cryptomonnaies ; Google a depuis nettement progressé dans la détection de ce type de fraude.


Ce qu'un attaquant en fait

L'attaque est triviale. Un acteur malveillant consulte le code source de votre page, copie la clé AIza... et appelle l'API de génération d'images de Gemini. C'est tout. Aucun accès à votre infrastructure, aucun identifiant à voler, aucun exploit sophistiqué. Juste votre clé et une requête HTTP — répétée en rafale, le tout facturé sur votre compte.


Êtes-vous exposé ?

Sauriez-vous répondre à ces questions :

  1. Les API Generative Language ou Gemini Agent Platform (anciennement Vertex AI) sont-elles activées dans l'un de vos projets GCP ?
  2. Certaines clés API sont-elles dépourvues de restriction d'API ou de restriction d'application ?
  3. Vos clés Maps ou Firebase partagent-elles la même clé que les API d'IA ?
  4. Avez-vous des clés de Service Account anciennes, inutilisées, ou dotées de rôles owner ou editor ?

Dès lors que vous dépassez la poignée de projets, vérifier tout cela manuellement à l'échelle de l'organisation n'est tout simplement pas réaliste.


Scannez votre organisation en quelques minutes

Chez DoiT, nous accompagnons des clients Google Cloud au quotidien. Nous avons développé gcp-apikey-check pour offrir à toute la communauté la même visibilité que celle dont bénéficient nos clients — gratuit et open source.

Terminal window
git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync
# Scan an entire organization
uv run gcpkeyscan.py --org-id YOUR_ORG_ID
# Or scan a single project
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

L'outil passe vos clés API au crible pour traquer précisément les mauvaises configurations à l'origine de ces pics de facturation : clés non restreintes, API Maps et IA cohabitant sur la même clé, clés Firebase sans restrictions d'application, règles de referrer trop permissives avec wildcards. Il met aussi en évidence les clés de Service Account anciennes, inutilisées ou aux permissions excessives, et vérifie si les politiques de votre organisation autorisent la création de clés SA. Les résultats sont étiquetés par sévérité (CRITICAL / HIGH / MED) et exportés en JSON et CSV pour que vous puissiez agir sans attendre.


Corrigez le tir — et demandez-vous si vous avez vraiment besoin de clés

L'essentiel à retenir : la meilleure clé API est celle qui n'existe pas.

Les recommandations de Google sont claires : évitez autant que possible les clés API et les clés de Service Account. Une clé API n'a pas d'identité, pas d'expiration par défaut, et pas de piste d'audit fine. Pour les services backend et les workloads GCP, il existe presque toujours une meilleure option :

  • Privilégiez Workload Identity Federation aux clés de Service Account pour l'authentification serveur à serveur
  • Utilisez les Application Default Credentials avec des rôles IAM pour les workloads exécutés sur GCP
  • Appelez Gemini côté serveur via IAM — n'exposez jamais une clé dans du code côté client

Si vous devez vraiment recourir à des clés API — pour des intégrations Maps, des SDK client Firebase ou d'autres usages légitimes côté client — restreignez-les correctement :

  • Limitez chaque clé aux seules API dont elle a besoin
  • Ajoutez des restrictions d'application : referrer HTTP pour le web, bundle ID pour le mobile, plage IP pour le serveur
  • Ne placez jamais une clé Maps ou Firebase sur la même clé que Gemini ou toute autre API d'IA
  • Désactivez les API que vous n'utilisez pas activement
  • Mettez en place des alertes de facturation pour qu'un pic ne passe pas inaperçu pendant des jours

Pour les clés de Service Account que vous ne pouvez pas encore supprimer : faites tourner toute clé de plus de 90 jours, retirez les rôles owner et editor, et supprimez celles qui n'ont pas servi récemment.

Bonne nouvelle : Google a durci les paramètres par défaut pour la création de nouvelles clés API ; il n'est plus possible d'en créer une sans restriction. Google AI Studio génère également des clés limitées à la seule API Gemini. Cela ne résout pas tout, mais des défauts plus sains, c'est déjà ça de pris.


N'attendez pas la facture

Google s'oriente vers des paramètres par défaut plus stricts, mais l'échéance et l'effet réel de ces changements sur les clés déjà déployées dans vos projets restent en suspens. Les développeurs qui partagent leurs mésaventures ignoraient être exposés jusqu'à ce qu'il soit trop tard.

Lancez le scan dès aujourd'hui. Faites l'inventaire. Corrigez les pires cas, puis travaillez à éliminer les clés partout où c'est possible.

https://github.com/doitintl/gcp-apikey-check