Clés API Google et Gemini : auditez votre exposition avec gcloud

Pendant plus de dix ans, Google a explicitement conseillé aux développeurs d’intégrer leurs clés API directement dans le code JavaScript côté client. La documentation Firebase indique encore aujourd’hui que les clés API ne sont pas des secrets. La documentation Google Maps invite à coller la clé dans le HTML de la page. Ce conseil était correct — jusqu’à l’arrivée de Gemini.

Ce qui a changé avec l’API Gemini

Google Cloud utilise un format de clé unique (AIza...) pour deux usages fondamentalement différents : l’identification publique de projet et l’authentification à des services sensibles. Pendant des années, ces clés servaient uniquement à identifier un projet pour la facturation et à appeler des APIs publiques comme Maps ou YouTube. Elles n’étaient pas des credentials d’authentification au sens strict.

Quand vous activez l’API Gemini (Generative Language API) dans un projet Google Cloud, toutes les clés API existantes de ce projet héritent silencieusement d’un accès aux endpoints Gemini. Aucun avertissement. Aucune notification par email. Aucune confirmation. Une clé créée il y a trois ans pour afficher une carte sur votre site web peut désormais interroger Gemini, accéder aux fichiers uploadés dans votre projet et générer des coûts d’utilisation.

C’est une escalade de privilèges rétroactive. La clé n’a pas changé. Le code de votre site n’a pas changé. Mais ses permissions, elles, ont changé — sans que vous le sachiez.

L’ampleur du problème

Des chercheurs en sécurité ont analysé l’archive Common Crawl de novembre 2025, un snapshot de plusieurs centaines de téraoctets de pages web publiques. Ils ont identifié 2 863 clés API Google actives et vulnérables à cette escalade de privilèges. Parmi les organisations concernées : des institutions financières, des cabinets de recrutement internationaux, et Google lui-même. Certaines clés de Google étaient publiquement déployées depuis au moins février 2023, bien avant l’existence de l’API Gemini.

Le problème ne se limite pas aux clés déjà exposées. Par défaut, toute nouvelle clé créée dans la console Google Cloud est “non restreinte”, ce qui signifie qu’elle donne accès à toutes les APIs activées dans le projet — y compris Gemini si elle est activée. Un développeur qui crée une clé pour un widget Maps génère sans le savoir une credential capable d’appels IA.

Ce qu’un attaquant peut faire

L’attaque est simple. L’attaquant visite votre site, inspecte le code source, copie la clé AIza... depuis l’embed Google Maps, puis exécute :

curl "https://generativelanguage.googleapis.com/v1beta/models?key=AIzaSy..."

Si la réponse est un 200 OK avec la liste des modèles disponibles plutôt qu’un 403 Forbidden, la clé a accès à Gemini. L’attaquant peut alors lire les fichiers uploadés dans votre projet via l’endpoint /files/, accéder au contenu mis en cache via /cachedContents/, et générer des appels IA facturés à votre compte. Il n’a jamais touché votre infrastructure.

Auditer votre exposition avec gcloud

La bonne nouvelle : l’audit est rapide avec la CLI gcloud. Voici la procédure complète.

Étape 1 : lister vos projets

gcloud projects list --format="value(projectId)"

Cette commande liste tous les projets Google Cloud auxquels votre compte a accès. Notez les identifiants de projet — vous en aurez besoin pour les étapes suivantes.

Étape 2 : vérifier si l’API Gemini est activée

Pour chaque projet, vérifiez si l’API Generative Language est activée :

gcloud services list --enabled \
  --project=MON_PROJET \
  --filter="name:generativelanguage.googleapis.com"

Si la commande ne retourne rien, votre projet n’est pas concerné par cette faille. Si elle retourne generativelanguage.googleapis.com, passez à l’étape suivante.

Étape 3 : inspecter les clés API du projet

Listez toutes les clés API du projet :

gcloud services api-keys list --project=MON_PROJET

Pour chaque clé, examinez ses restrictions :

gcloud services api-keys describe \
  projects/NUMERO_PROJET/locations/global/keys/ID_CLE \
  --project=MON_PROJET

Cherchez le champ restrictions dans la réponse. Une clé sans restrictions (restrictions: {}) ou avec generativelanguage.googleapis.com dans sa liste d’APIs autorisées peut accéder à Gemini.

Script d’audit multi-projets

Si vous gérez plusieurs projets, ce script automatise l’audit complet :

#!/bin/bash
echo "=== Audit clés API Google Cloud / Gemini ==="
for project in $(gcloud projects list --format="value(projectId)"); do
  result=$(gcloud services list --enabled --project="$project" \
    --filter="name:generativelanguage.googleapis.com" \
    --format="value(name)" 2>/dev/null)
  if [ -n "$result" ]; then
    echo ""
    echo "⚠️  Projet exposé : $project"
    echo "   Clés API présentes :"
    gcloud services api-keys list --project="$project" \
      --format="table(displayName,uid,createTime)" 2>/dev/null
  fi
done
echo ""
echo "=== Audit terminé ==="

Ce script identifie tous les projets où l’API Gemini est activée et liste les clés associées. Pour chaque clé listée, vérifiez ensuite si elle est présente dans du code public (dépôts Git, JavaScript côté client, documentation).

Clés API vs Service Account : ne pas confondre

Une précision importante : les clés API au format AIza... sont différentes des Service Account JSON. Les Service Account JSON sont des credentials d’authentification pour les applications serveur — ils ont toujours été traités comme des secrets. Les clés API, elles, étaient historiquement conçues pour être publiques dans certains contextes. C’est précisément cette distinction que l’arrivée de Gemini a rendue obsolète pour les projets où l’API est activée.

Que faire si vous êtes exposé

Si vous trouvez une clé sans restriction dans un projet où Gemini est activée, et que cette clé est présente dans du code public, agissez immédiatement. Révoquez la clé depuis la console Google Cloud (APIs & Services > Credentials) et créez-en une nouvelle. Lors de la création, restreignez explicitement la nouvelle clé aux seules APIs dont elle a besoin — Maps JavaScript API uniquement pour un widget cartographique, par exemple.

Consultez ensuite les Cloud Audit Logs pour détecter d’éventuels appels non autorisés à l’API Gemini. Si vous constatez des appels suspects, soumettez un dossier de support facturation à Google Cloud pour contester les charges.

Pour les nouvelles clés, appliquez systématiquement le principe du moindre privilège : une clé par usage, avec des restrictions d’API et de référent HTTP explicites.

Ce que Google fait

Google a engagé plusieurs actions correctives. Les clés identifiées comme exposées publiquement sont désormais bloquées pour l’accès à l’API Gemini, et les propriétaires sont notifiés. Les nouvelles clés créées via Google AI Studio seront par défaut limitées à Gemini uniquement, ce qui empêche les usages croisés non intentionnels. Google travaille également à notifier proactivement les propriétaires de clés exposées.

Ces mesures sont utiles, mais elles ne couvrent pas les clés exposées que Google n’a pas encore détectées. L’audit manuel reste la seule façon d’avoir une visibilité complète sur votre exposition.

Si vous utilisez Google Cloud et n’avez jamais audité vos clés API, c’est le bon moment. La procédure prend moins de dix minutes. Contactez-nous si vous souhaitez un accompagnement sur la sécurisation de vos projets Google Cloud.

Sources

1. Truffle Security Co., Google API Keys Weren’t Secrets. But then Gemini Changed the Rules. trufflesecurity.com (25 février 2026)
2. Google, Getting information about API keys, API Keys API Documentation. docs.cloud.google.com
3. Google, Blocked or non-working API keys, Gemini API Troubleshooting. ai.google.dev
4. Firebase, Security Checklist — API keys are not secret. firebase.google.com