Vous supprimez une clé API Google qui a fuité , et l'interface vous confirme que c'est bien réglé, que la clé ne fonctionne plus. Alors vous commencez à vous détendre en vous disant que vous avez bien fait votre boulot.

BAH NAN !

Car vous ne le savez pas, mais cette clé va continuer de fonctionner encore durant 23 minutes. C'est en tout cas ce qu'ont mesuré les chercheurs d'Aikido Security en testant ce truc tout bête de révoquer une clé, puis de taper sur l'API en boucle pour voir quand ça s'arrêtait vraiment.

Et résultat des courses, une clé API classique survit en moyenne 16 minutes après sa suppression, et jusqu'à 23 minutes dans le pire des cas. Cela veut dire que pendant tout ce temps, un attaquant qui a récupéré votre clé peut continuer de l'utiliser peinard. Et vous n'avez aucun moyen de couper plus vite, ni même de savoir quand ça s'arrête pour de bon.

Ce sont les clés API de Schrödinger le bordel... Techniquement comme vous vous en doutez, c'est surtout une histoire de propagation car Google ne tue pas la clé d'un coup sur tous ses serveurs, mais l'info se diffuse petit à petit, et chaque serveur arrête de l'accepter à son rythme. Le souci, c'est que ce délai et largement suffisant par exemple pour vider un bucket pendant que vous pensez que le danger est écarté.

Le plus beau, c'est que Google sait parfaitement faire vite quand il veut puisque les clés de compte de service, elles, sont coupées en 5 secondes. et les clés Gemini récentes en 1 minute. Du coup, ces 16 minutes de moyenne sur les vieilles clés API n'ont rien d'une fatalité technique... c'est juste un choix ! Aikido a bien sûr remonté le problème, et Google a bizarrement classé le ticket en « won't fix », en expliquant que ce délai de propagation était une propriété connue du système, et pas une faille de sécurité.

Donc si vous gérez des clés Google en prod, partez du principe qu'une clé compromise reste exploitable une bonne demi-heure après sa révocation. Et surtout, mettez en place des plafonds de dépenses bien serrés sur votre projet parce que le vrai cauchemar, c'est moins l'accès que la facture qui débarque ensuite. On a déjà vu des devs se prendre des notes à cinq chiffres à cause d'une clé qui traîne, et des utilisateurs Google Cloud facturés par erreur .

Source : Aikido Security

Hier soir, le compte Google Cloud de Railway est passé en statut restreint. Du jour au lendemain, sans préavis et sans la moindre explication.

Railway, pour ceux qui ne connaissent pas, c'est un service américain qui permet aux développeurs et aux startups de mettre un site ou une application en ligne en quelques clics, sans avoir à louer ni configurer eux-mêmes des serveurs.

Dans le jargon, on appelle ça un PaaS, une plateforme d'hébergement clé en main. Des milliers d'entreprises s'en servent pour faire tourner leurs services au quotidien. Sauf que Railway, lui, fait tourner son propre tableau de bord, son API et son control plane (la partie qui orchestre toute la plateforme) sur Google Cloud. Donc quand Google a coupé, tout est tombé.

Résultat : environ six heures de panne. Les utilisateurs se sont retrouvés avec des erreurs "no healthy upstream" en cascade, impossible de se connecter, impossible de déployer quoi que ce soit. Le pire dans l'histoire, c'est que Railway n'est pas un petit client de passage. La boîte dépense plus de 10 millions de dollars par an chez Google Cloud. Même ça n'a pas suffi à éviter le débranchement automatique.

Le ton des équipes Railway est agacé. Angelo Saraceno, ingénieur chez eux, a lâché que leurs contacts chez Google étaient eux-mêmes confus et que les clients étaient furieux. Et cette phrase, qui résume tout : "nos clients se fichent que ce soit Google, c'est à nous d'assumer notre disponibilité". Difficile de leur donner tort.

Ce n'est pas la première fois. Railway avait déjà déménagé une partie de son infrastructure en colocation (des serveurs loués dans un datacenter, qu'on gère soi-même) en 2024, justement parce que les problèmes avec Google Cloud posaient un risque existentiel à leur activité.

Sauf qu'ils avaient gardé le control plane chez Google. Mauvaise idée, visiblement. Et en 2024, Google avait déjà fait exactement le même coup au fonds de pension australien UniSuper, suspendu une semaine entière sans raison claire.

Là où ça pique, c'est l'angle métier. Railway est un PaaS. Google Cloud propose aussi un PaaS. Autrement dit, Railway hébergeait son business chez un concurrent direct, qui peut le débrancher quand il veut, par un automatisme mal réglé ou autre chose. Vous voyez le piège. Confier sa plateforme d'hébergement à quelqu'un qui vend exactement le même service, c'est lui donner les clés et la corde.

Source : The Register

Pour éviter de finir un jour entre les mains d'un géant américain ou d'un fonds spéculatif, le fondateur d'Infomaniak a pris une décision radicale : céder la majorité de ses droits de vote à une fondation. Un bouclier juridique inédit pour graver la protection de la vie privée et l'écologie dans le marbre.

Un truc franchement rageant remonte du côté de chez Google Cloud, et c'est The Register qui a mené l'enquête. Plusieurs développeurs ont vu leur facture Google Cloud exploser entre 3000 et 10000 dollars en quelques minutes, pour des services qu'ils n'ont jamais utilisés : génération vidéo Veo 3, tokens du modèle Gemini, le tout via leurs clés API Maps. Et le pire, c'est qu'ils avaient suivi à la lettre les recommandations officielles de Google.

La doc Google vous dit en effet de mettre votre clé Maps en clair côté client (dans le JavaScript de votre site, par exemple), parce qu'elle sert à afficher une carte dans un navigateur. Sauf que voilà, si vous activez sur votre projet Google Cloud d'autres APIs (comme Gemini ou Veo, l'outil de génération vidéo de Google), la même clé peut être utilisée pour appeler ces services.

Un bot malveillant trouve la clé sur n'importe quel site (le code source d'une page web est lisible par tout le monde), s'en sert pour générer des milliers de vidéos IA, et c'est le proprio du projet qui paie l'addition.

Le plus pénible, ce sont les spending caps, ces plafonds de dépenses que Google met en avant comme garde-fou. En pratique, ils ne déclenchent qu'une alerte par mail, pas une coupure réelle des services.

Vous recevez l'alerte alors que la facture grimpe déjà depuis dix minutes, et le temps de réagir, c'est déjà fini. Plusieurs devs disent avoir vu leur compte passer de quelques euros à plusieurs milliers en moins d'une heure. Ça pique.

Et Google ? La firme refuse les remboursements en parlant d'un problème "industrie-wide", autrement dit "tout le monde a ce souci, c'est pas notre faute". Pratique pour eux, moins pour les développeurs qui se retrouvent avec une note salée pour des services qu'ils n'ont jamais demandés.

Le vrai sujet, c'est le mélange clé Maps publique par design + accès Gemini activé par défaut sur le même projet. Ce n'est pas une faille au sens technique du terme, c'est une configuration que Google a choisie et qui transforme chaque clé Maps en bombe potentielle pour le portefeuille de celui qui l'utilise.

Si vous bossez sur Google Cloud, allez donc vérifier que Gemini et Veo ne sont pas activés sur les projets qui n'en ont pas besoin, et restreignez vos clés Maps à des domaines précis dans la console. C'est moche, mais visiblement c'est à vous de le faire.

Source : The Register