Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Clés API volées - Comment éviter une facture à 82 000 dollars

Par : Korben
4 mars 2026 à 12:04

82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !

Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !

Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.

Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.

Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.

Scanner vos secrets existants

Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.

TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :

brew install trufflehog
trufflehog git https://github.com/user/project --only-verified

Le flag --only-verified c'est le truc important, ça teste si les secrets trouvés sont encore ACTIFS. Parce que trouver une vieille clé révoquée, on s'en fiche. Attention, ça ne marche pas sur les repos privés sans token d'accès.

Y'a aussi Nosey Parker qui fait le même genre de boulot mais perso, je trouve TruffleHog plus complet pour les clés cloud, même si Nosey Parker est plus rapide pour les gros repos.

Après si vous bossez avec des clés Google spécifiquement, cherchez le pattern AIza dans votre code. Un simple grep suffit :

grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"

Empêcher les fuites à la source

Scanner c'est bien, mais empêcher les secrets d'atterrir dans Git, c'est mieux. Et pour cela, rien de plus simple... Suffit d'installer un pre-commit hook.

git-secrets d'AWS fait exactement ça :

brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws

Du coup, chaque git commit vérifie automatiquement qu'il n'y a pas de clé AWS qui traîne. Vous pouvez ajouter vos propres patterns (genre AIza pour Google) :

git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'

Le deuxième pattern, c'est pour les clés OpenAI (format sk-proj-). D'ailleurs, stockez TOUT dans des fichiers .env et vérifiez que .env est dans votre .gitignore. Ça devrait être un réflexe ! Le piège classique c'est surtout le fichier .env.example qui contient en fait de vraies clés... c'est du vu et revu sur GitHub.

Pour aller plus loin, Vault de HashiCorp gère également vos secrets de manière centralisée avec du chiffrement, de la rotation automatique et des audit logs. C'est carrément le niveau supérieur notamment pour les équipes. C'est bien plus safe que le .env .

Détecter un vol avant la catastrophe

Notre dev mexicain a découvert sa facture APRÈS 48 heures. Deux jours, c'est une éternité alors voilà comment réagir en minutes, et pas en jours.

Sur Google Cloud, allez dans Billing > Budgets & Alerts. Créez un budget avec des seuils à 50%, 90% et 100% de votre budget mensuel. Activez les notifications par email ET par Pub/Sub pour déclencher une Cloud Function qui coupe automatiquement les clés si le seuil est dépassé.

Chez OpenAI, c'est dans Settings > Billing > Usage limits. Vous pouvez définir un hard cap mensuel. Au-delà... plus rien ne passe. Même chose à peu près pour Claude d'Anthropic aussi...

Et surtout, activez la rotation automatique de vos clés. Sur Google Cloud :

gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID

Les restrictions d'API c'est pas un luxe donc sur chaque clé, limitez les services autorisés (Gemini uniquement si c'est son usage), les IPs sources et le nombre de requêtes par minute. Sauf si vous aimez les surprises à 5 chiffres sur votre relevé bancaire, une clé sans restriction, c'est une carte bleue sans plafond.

Perso, je me suis mis des alertes sur tous mes comptes cloud, que ce soit AWS, GCP ou Azure. Genre, si ça dépasse 50 balles en une journée... hop, notification sur le téléphone. Finalement, c'est 5 minutes de config qui peuvent vous éviter des mois de galère.

Source

Envmap - Fini les fichiers .env qui traînent et finissent sur GitHub

Par : Korben
17 janvier 2026 à 19:00

Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?

Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !

Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !

Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env ( Source )

Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap .

C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).

Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.

Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.

Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.

D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur SOPS ou encore ma réflexion sur l'usage de GitLab pour vos projets sensibles.

Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !

❌
❌