Pour mesurer ce délai, Aikido a créé puis supprimé des clés API tout en envoyant des requêtes d’authentification en continu. Sur 10 essais, les requêtes ont continué à réussir jusqu’à la fin de la propagation de la révocation, d’où la fenêtre observée de 8 à 23 minutes, avec une médiane d’environ 16 minutes.
En pratique, cela signifie qu’une clé affichée comme « supprimée » dans l’interface Google Cloud peut encore fonctionner temporairement sur certaines parties de la plateforme.
Lorsqu’une clé API est exposée ou compromise, la première réaction consiste généralement à la supprimer immédiatement pour bloquer l’accès. Mais ce délai de propagation crée une période pendant laquelle un attaquant peut continuer à l’utiliser.
Durant cette fenêtre, une personne disposant de la clé pourrait par exemple :
Les chercheurs ont confirmé ce comportement avec des clés donnant accès à Gemini, et ont observé le même phénomène avec d’autres API Google Cloud, notamment BigQuery et Google Maps. Le problème ne semble donc pas lié à un service spécifique, mais au type de credential (clé API) lui‑même.
D’après les informations publiées après la divulgation du problème, Google aurait d’abord considéré ce comportement comme un simple délai de propagation normal dans un système distribué plutôt que comme une faille critique. Certains rapports indiquent que le ticket de sécurité avait même été fermé avec la mention « won’t fix ».
Après réexamen, le signalement a finalement été rouvert et classé en interne comme bug P0, une catégorie réservée aux problèmes nécessitant une investigation prioritaire.
La cause technique reste liée à la propagation progressive des mises à jour de révocation à travers l’infrastructure d’authentification de Google. Selon le serveur qui traite la requête, la clé peut donc être rejetée immédiatement… ou encore acceptée pendant plusieurs minutes.
En attendant qu’une solution garantisse une révocation immédiate, les équipes sécurité doivent partir du principe qu’une clé API supprimée peut rester active pendant un court laps de temps.
Quelques bonnes pratiques :
Considérer la suppression comme une mesure à effet différé
Prévoir une fenêtre de risque temporaire — potentiellement jusqu’à 30 minutes — pendant laquelle la clé peut encore fonctionner.
Surveiller les logs et la facturation après révocation
Des appels API inattendus ou une hausse soudaine de consommation juste après la suppression peuvent signaler une utilisation abusive durant la propagation.
Restreindre les clés API autant que possible
Google recommande d’appliquer des restrictions comme les adresses IP autorisées, les referrers ou la liste des API utilisables afin de limiter l’impact d’une fuite.
Faire tourner les credentials rapidement
Plutôt que de compter uniquement sur la suppression, il est préférable de générer une nouvelle clé et de migrer les services vers celle‑ci le plus vite possible.
Cette découverte rappelle une réalité technique importante : dans les architectures cloud distribuées, les changements de configuration — y compris la révocation de credentials — ne sont pas toujours appliqués instantanément partout.
Pour les développeurs et les équipes sécurité, la conclusion est simple : une clé “supprimée” ne signifie pas toujours “inactive immédiatement”. Les procédures de réponse aux incidents doivent donc intégrer ces délais de propagation lorsqu’un credential sensible est compromis.