Abus de clés API Gemini : le correctif est là, avec une date butoir

L'essentiel

• Google abandonne les clés API standard de l'API Gemini en deux étapes : les clés standard non restreintes cesseront de fonctionner le 19 juin 2026 ; toutes les clés standard cesseront de fonctionner en septembre 2026
• Si vous utilisez des clés non restreintes, le temps presse pour les restreindre ou basculer vers le nouveau type de clé d'authentification
• Les nouvelles clés d'authentification sont rattachées à un compte de service, ce qui répond au vecteur d'abus que j'évoquais dans un précédent article
• Utilisez notre scanner gratuit pour détecter vos clés exposées : github.com/doitintl/gcp-apikey-check

Un peu de contexte

Il y a quelques semaines, j'expliquais comment des acteurs malveillants récupéraient des clés API Google non restreintes et sans périmètre sur des pages web ou via des clés publiées par mégarde. Une fois la clé en main, ces acteurs généraient massivement du contenu Gemini avant de disparaître, laissant au propriétaire de la clé une facture salée, souvent de plusieurs dizaines de milliers de dollars, parfois davantage. Nous avons traité notre lot de ces affaires et le subreddit googlecloud regorge de récits édifiants.

Récemment, Google a modifié les clés API Gemini nouvellement créées. L'éditeur semble enfin passer à l'action pour combler la faille côté clés existantes, ce qui aura un impact sur les utilisateurs de l'API Gemini. Les changements vont dans le bon sens, mais le calendrier est serré !

Ce qui change

Google fait passer l'API Gemini des clés standard aux clés d'authentification (auth keys).

Les clés standard associent les requêtes à un projet Google Cloud pour la facturation et les quotas, mais elles n'identifient pas l'auteur de l'appel. Sans identité de l'appelant, les contrôles d'accès applicables restent limités.

Les clés d'authentification, elles, sont rattachées à un compte de service Google Cloud précis. Les requêtes effectuées avec une clé d'authentification sont traitées sous l'identité de ce compte de service, ce qui permet un véritable contrôle d'accès via IAM. Google indique également que les clés d'authentification bénéficieront de mécanismes anti-fraude plus réactifs.

Calendrier de migration :

• 19 juin 2026 : l'API Gemini rejettera les requêtes provenant des clés standard non restreintes. Les clés standard assorties de restrictions d'API explicites continueront de fonctionner.
• Septembre 2026 : l'API Gemini rejettera les requêtes provenant de toutes les clés standard. Il faudra avoir basculé sur des clés d'authentification d'ici là.

Toutes les clés nouvellement créées dans Google AI Studio sont déjà des clés d'authentification par défaut.

En quoi les clés d'authentification changent-elles la donne ?

Avec une clé standard sans périmètre d'API, n'importe quel acteur malveillant qui mettait la main dessus pouvait la tester contre l'API Gemini et générer du contenu facturé sur votre compte. C'est précisément l'attaque décrite dans mon précédent article.

Les clés d'authentification comblent cette faille à plusieurs niveaux. Elles sont par défaut limitées à l'API Gemini : une clé d'authentification fuitée ne peut donc pas servir avec d'autres API Google. Surtout, elles sont rattachées à un compte de service, ce qui permet d'appliquer des contrôles d'accès IAM — chose impossible avec les clés standard. Les requêtes effectuées avec une clé d'authentification apparaissent aussi dans les journaux d'audit, et la détection de secrets fuités de Google peut agir plus vite puisqu'il existe une identité à révoquer.

Cela dit, les clés d'authentification ne sont pas une solution parfaite. Une clé d'authentification fuitée ou exfiltrée pourrait toujours servir à générer du contenu et alourdir la facture. On ignore encore à quel point les systèmes anti-fraude de Google seront efficaces dans ces cas.

La meilleure approche reste de se passer entièrement de clés API. Si vous utilisez Gemini côté backend, envisagez de migrer vers la Gemini Enterprise Agent Platform, qui s'appuie sur des identifiants IAM à durée de vie courte plutôt que sur des clés statiques : rien à divulguer, rien à faire tourner.

Ce que vous devez faire

Avant le 19 juin 2026 : sécurisez toutes les clés standard non restreintes

Lancez le scanner pour repérer les clés non restreintes dans toute votre organisation GCP :

git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync

# Scan an entire organization (**recommended**)
uv run gcpkeyscan.py --org-id YOUR_ORG_ID

# Or a single project
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

Pour chaque clé non restreinte identifiée, vous avez deux options :

Option 1 — Restreindre la clé (vous gagnez du temps jusqu'en septembre) : Dans Google AI Studio, ouvrez la page API Keys, repérez les clés marquées "Unrestricted", survolez l'étiquette, cliquez sur "Add restrictions" et sélectionnez "Restrict to Gemini API only."

Option 2 — Migrer vers une clé d'authentification dès maintenant (recommandé) :

1. Rendez-vous sur AI Studio API Keys
2. Cliquez sur "Create API key" — les nouvelles clés sont désormais des clés d'authentification par défaut
3. Mettez à jour le code de votre application, les variables d'environnement et les configurations de déploiement avec la nouvelle clé
4. Testez, testez et retestez
5. Supprimez ou révoquez l'ancienne clé standard

Consultez la documentation de migration de Google pour plus de détails en cas de difficulté.

Avant septembre 2026 : migrez les clés standard restantes

Les clés standard que vous avez restreintes lors de la première étape cesseront de fonctionner en septembre. Reprenez les mêmes étapes de migration pour créer leurs remplaçantes en clés d'authentification et mettre à jour vos applications.

Pour aller plus loin

Migrer vers les clés d'authentification est un progrès, mais la bonne pratique de fond reste inchangée.

Pour la plupart des workloads Google Cloud : Workload Identity Federation et Application Default Credentials avec rôles IAM sont de meilleures options — aucune clé à divulguer, aucune rotation à gérer, et des pistes d'audit en place par défaut. Si vous utilisez l'API Gemini en production, nous recommandons de basculer vers Gemini Enterprise Agent Platform, qui s'appuie sur des identifiants à courte durée de vie plutôt que sur des clés API statiques, et propose d'autres fonctionnalités utiles en production comme le support éditeur.

Pour les applications Maps et Firebase : ces clés restent des clés API standard. Appliquez néanmoins les bonnes pratiques : restreignez chaque clé à la (ou aux) API dont elle a besoin, ajoutez des restrictions applicatives, et ne mélangez jamais sur une même clé Maps ou Firebase avec Gemini ou d'autres API d'IA. Dans la mesure du possible, isolez les clés Gemini dans un projet dédié, par sécurité.

Prochaines étapes

L'échéance du 19 juin se rapproche. Si vous n'avez pas encore audité vos clés, c'est le moment :

• Scannez votre organisation : github.com/doitintl/gcp-apikey-check
• Contexte sur le vecteur d'abus : Your Google API Key Might Be Paying for Someone Else's AI
• Guide de migration de Google : ai.google.dev/gemini-api/docs/api-key#migrate-to-auth-key
• Guide de migration Google Enterprise Agent Platform docs.cloud.google.com/gemini-enterprise-agent-platform/models/migrate/migrate-google-ai.