En bref Lorsque vous supprimez une clé API Google, il est indiqué qu'elle est immédiatement supprimée. Nos tests indiquent environ 23 minutes. Pendant cette période, un attaquant disposant d'une clé divulguée conserve l'accès à vos données et aux API activées (y compris Gemini). Vous n'avez aucun moyen de la révoquer plus rapidement ou de confirmer quand elle cesse de fonctionner. Google a clôturé notre rapport initial avec la mention « ne sera pas corrigé ».
Mise à jour du vendredi 22 mai 2026 : Google a rouvert notre rapport et traite cela comme un bug P0.
Lorsque vous supprimez une clé API, vous vous attendez à ce que l'accès prenne fin immédiatement.
Les clés API Google ne fonctionnent pas de cette manière. La révocation se propage progressivement à travers l'infrastructure de Google. Certains serveurs rejettent la clé en quelques secondes, d'autres continuent de l'accepter pendant 23 minutes.
Un attaquant détenant votre clé supprimée peut continuer à envoyer des requêtes jusqu'à ce que l'une d'elles atteigne un serveur qui n'a pas encore été mis à jour. Si Gemini est activé sur le projet, il peut extraire les fichiers que vous avez téléchargés et exfiltrer les conversations mises en cache.
La console GCP n'affichera pas la clé et ne vous indiquera pas qu'elle fonctionne toujours. Vous faites confiance à l'infrastructure de Google pour se mettre à jour à terme.
L'authentification ne devrait pas être à cohérence éventuelle
De nombreux services de Google Cloud sont, par conception, à cohérence éventuelle. Dans ce modèle, les mises à jour se propagent progressivement sur ses serveurs plutôt qu'en une seule fois. Ce compromis permet à Google de s'adapter à l'échelle mondiale et de rester rapide, et pour la plupart des services, le décalage est invisible. Mais pour l'authentification, ce compromis est plus difficile à justifier.
Les retards de révocation des identifiants sont exploitables. Il y a quelques mois, Eduard Agavriloae a révélé un délai de 4 secondes qui permettait à des clés d'accès AWS supprimées de créer de nouveaux identifiants. Quatre secondes étaient suffisantes pour avoir un impact sur AWS.
Compte tenu de l'attention récente portée aux clés API Google utilisées pour accéder à Gemini, nous avons entrepris de mesurer la durée pendant laquelle la fenêtre de révocation des clés API de Google reste ouverte.
Qu'est-ce qu'une fenêtre de révocation ?
La fenêtre de révocation est le temps écoulé entre le moment où vous supprimez une clé et la dernière authentification réussie.
Si la fenêtre est de quelques microsecondes, le comportement correspond à ce que les utilisateurs attendent. Si elle est plus longue, chaque seconde supplémentaire donne aux attaquants plus de temps pour abuser d'une clé volée.
Mesurer la fenêtre de révocation
Pour mesurer la fenêtre de révocation des clés API de Google, nous avons effectué 10 essais sur deux jours.
Lors de chaque essai, nous avons créé une clé API, l'avons supprimée et avons envoyé 3 à 5 requêtes authentifiées par seconde jusqu'à ce qu'aucune réponse valide ne soit renvoyée pendant plusieurs minutes.
Nous avons choisi ce débit car nous ne contrôlons pas la manière dont Google achemine nos requêtes vers différents serveurs d'authentification à travers le monde. Le volume était destiné à passer par le plus grand nombre possible de ces serveurs par essai, tout en respectant l'infrastructure de Google. Nous ne pouvons pas dire si un débit de requêtes plus élevé prolongerait la fenêtre observée. Un attaquant n'a aucune raison de limiter le débit comme nous l'avons fait, il est donc important de noter que nos chiffres pourraient ne pas représenter le pire des scénarios.
Par souci d'exhaustivité, nous avons également vérifié notre travail quelques semaines plus tard pour nous assurer que le comportement observé n'était pas dû à des problèmes de réseau transitoires.
23 minutes
Sur dix essais, la fenêtre la plus longue a duré près de 23 minutes ! C'est une durée incroyablement longue pour qu'une clé supprimée puisse encore s'authentifier avec succès.
La fenêtre la plus courte était de près de 8 minutes, et la médiane était d'environ 16 minutes. Sur l'ensemble des essais, le taux de succès était très imprévisible : une minute après la suppression, un essai a vu 79 % des requêtes réussir tandis qu'un autre n'en a vu que 5 %.
Un attaquant détenant une clé volée ne constate pas de coupure nette ou de dégradation prévisible. L'accès continue de fonctionner, de manière irrégulière, jusqu'à ce qu'il s'arrête finalement.
Suivi d'un seul essai dans la console de GCP.
Pour illustrer l'incohérence de l'infrastructure de Google, nous avons surveillé l'un de nos essais en utilisant le graphique « Traffic by Credential » dans GCP. La ligne inférieure (bleue) indique les authentifications réussies et reflète la durée de la fenêtre de révocation.
Nous ne nous attendions pas à voir d'autres données, mais une deuxième ligne est apparue. La ligne supérieure (verte) représente les requêtes rejetées et est étiquetée apikey:UNKNOWN. Nous avions (à tort) supposé que les requêtes invalides seraient simplement abandonnées sans aucune attribution de projet. Au lieu de cela, GCP les inclut dans ce graphique.
Pour mieux comprendre le mystérieux apikey:UNKNOWN valeur, nous avons tenté de nous authentifier avec une clé API supprimée depuis plusieurs jours. Étonnamment, ces requêtes sont apparues dans le même graphique, regroupées dans le même apikey:UNKNOWN groupe.
Notre meilleure hypothèse est que Google préserve l'attribution de projet après la suppression d'une clé au cas où les utilisateurs décideraient de restaurer l'identifiant.
Pour les équipes IR enquêtant sur un identifiant divulgué, la apikey:UNKNOWN valeur peut être déroutante. Toute requête effectuée avec une clé API Google supprimée est regroupée dans la même catégorie UNKNOWN, ce qui rend difficile de déterminer quelles requêtes sont liées à un identifiant particulier. Une requête dans ce groupe pourrait signifier qu'un acteur de la menace tente toujours de s'authentifier avec la clé supprimée, ou il pourrait s'agir d'un service légitime fonctionnant avec une clé obsolète et non liée.
Si vous êtes dans la fenêtre de révocation de 23 minutes, recherchez les authentifications valides utilisant la clé divulguée. Si vous êtes en dehors de cette fenêtre, le risque semble extrêmement faible.
Différences régionales en matière de cohérence
Nous avons mené la première expérience depuis une adresse IP résidentielle sur la côte Est des États-Unis. Nous avons émis l'hypothèse que l'exécution d'une expérience similaire sur des VM dans différentes régions GCP pourrait révéler des incohérences supplémentaires.
Nous avons démarré une VM dans trois régions : us-east1, europe-west1, et asia-southeast1. Nous avons ensuite effectué 5 essais. Pour chaque essai, nous avons supprimé une seule clé API et envoyé des requêtes depuis chacune des trois VM en parallèle.
Deux choses se sont démarquées. Premièrement, immédiatement après la suppression d'une clé, les VM dans différentes régions ont enregistré des taux de réussite d'authentification très différents. Le tableau ci-dessous indique le pourcentage de requêtes valides dans la première minute par région.
Examinons l'essai 1 : us-east1 82%, europe-west1 60%, asia-southeast1 32 %. Les VM plus éloignées des États-Unis ont détecté la suppression plus rapidement, ce qui est l'inverse de ce à quoi on pourrait s'attendre. Nous ne pouvons pas en déterminer la raison exacte de l'extérieur. Le routage des requêtes de Google est plus complexe que « la région de la VM est égale à la région du serveur », et une VM à Singapour ne communique pas nécessairement avec des serveurs à Singapour. Cependant, le schéma était cohérent sur l'ensemble des essais, ce qui suggère que l'infrastructure régionale, la mise en cache ou l'affinité de routage sont à l'origine de cette différence.
Deuxièmement, l'écart régional ne se limitait pas à la première minute. Sur l'ensemble de la période, asia-southeast1 avait un taux de réussite médian d'authentification des requêtes de 22 %, tandis que us-east1 et europe-west1 les deux se situaient autour de 49 %. L'Asie est restée plus basse minute après minute, pas seulement au début.
Quelles que soient les causes de ces différences, l'emplacement du serveur influence clairement le comportement d'une clé supprimée après sa suppression.
Autres identifiants Google
Nos essais ont tous utilisé des clés avec accès à Gemini, mais nous avons observé le même comportement avec des clés associées à d'autres API GCP, telles que BigQuery et Maps. Le délai est une propriété du type d'identifiant, et non des API activées sur le projet.
Par souci d'exhaustivité, nous avons testé deux autres types d'identifiants Google :
- Nouvelles clés API Gemini (préfixe AQ.). La suppression s'est propagée en ~1 minute.
- Clés de compte de service Google. La suppression s'est propagée en ~5 secondes.
Les deux fonctionnent à l'échelle de Google, et les deux révoquent beaucoup plus rapidement que les 23 minutes que nous avons mesurées pour les clés API Google.
Divulgation à Google
Nous avons signalé cela à Google. Google a clôturé le rapport avec la mention « ne sera pas corrigé ». La position de l'équipe, telle que nous la comprenons, est que le délai de propagation est une propriété connue du système et non un problème de sécurité.
Bien que Google documente publiquement que son API IAM est finalement cohérente, ils ne documentent pas spécifiquement ce comportement pour les clés API Google.
[Légende : Capture d'écran de la page de documentation de l'API IAM de Google.]
Attentes des utilisateurs non satisfaites
Les systèmes distribués à l'échelle de Google sont complexes, et il ne s'agit pas d'une critique de l'équipe IAM de GCP. Mais une fenêtre de révocation de 23 minutes est fondamentalement en contradiction avec ce que les utilisateurs attendent d'un bouton de suppression. L'écart entre cette attente et le comportement de Google met en évidence quatre problèmes :
1. L'interface utilisateur est extrêmement trompeuse.
Lorsque vous supprimez la clé, Google la retire de votre vue et vous indique : « Une fois supprimée, elle ne peut plus être utilisée pour effectuer des requêtes API. » Cette affirmation est manifestement fausse. L'utilisateur n'a aucun moyen de savoir si la clé est toujours active, aucun moyen d'accélérer la révocation, et aucun moyen de confirmer quand elle a complètement cessé de fonctionner.
2. Google a mis en place une révocation plus rapide pour d'autres types d'identifiants.
Les révocations d'identifiants de compte de service se propagent en environ 5 secondes. Le nouveau format de clé API de Gemini se propage en environ une minute. Les deux fonctionnent à l'échelle de Google. Les deux suggèrent que cela est également techniquement réalisable pour les clés API Google.
3. Les longues fenêtres de cohérence ne sont pas compatibles avec l'authentification.
L'attente lors de la suppression d'un identifiant est que celui-ci soit inactif. Même quelques secondes de délai sont importantes, comme l'a montré la recherche d'Eduard sur AWS l'année dernière.
4. Des fenêtres de révocation longues compromettent la création de justificatifs JIT.
Un fournisseur de services souhaitant générer dynamiquement des clés API Google doit prévoir un délai de 23 minutes après la révocation avant que la clé ne soit garantie inactive. Cela est incompatible avec le fonctionnement attendu du JIT.
Contourner le délai
Tant que Google ne proposera pas une révocation plus rapide, il incombe aux utilisateurs de combler cette lacune. Deux éléments peuvent aider.
1. Considérez la suppression d'une clé comme une opération de 30 minutes, et non comme une action instantanée.
Si vous réagissez à une clé API Google divulguée, supposez que la clé reste active pendant 30 minutes après avoir cliqué sur supprimer. Cela offre une petite marge au-delà des 23 minutes maximales que nous avons observées. Organisez le reste de votre réponse aux incidents en fonction de ce délai.
2. Surveillez l'utilisation pendant ce délai.
Dans la console GCP, sous « Enabled APIs and services », examinez les requêtes API par justificatif. Si vous constatez une utilisation inattendue de ce justificatif après sa suppression, quelqu'un pourrait être en train de l'exploiter activement.
Les fenêtres de cohérence éventuelle étendues sont un mauvais choix de conception pour la révocation des justificatifs. Tant que Google ne changera pas cela, considérez chaque suppression de clé comme une opération de 30 minutes et surveillez le délai pour détecter toute utilisation abusive.
