Ce qui se passe
Trois rapports distincts publiés ces derniers mois vont dans le même sens.
- Cequence (publié le 28 oct.) : un seul scanner, ~32 fausses identités d’IA, actif au moins de fin septembre à fin octobre. Chaque adresse cloud envoyait une rafale de 50 à 190 requêtes en huit secondes environ, puis passait à autre chose. Il a utilisé plus de 300 adresses en une seule journée, et aucune des adresses de fin septembre n’est réapparue un mois plus tard. L’article de CSO Online souligne que ce type de rotation rend les listes de blocage d’IP statiques bien moins utiles.
- GreyNoise (août) : un autre groupe s’est fait passer pour 13 robots d’IA depuis 824 adresses, dont aucune ne figurait dans les plages d’IP publiées par les entreprises. Les chemins les plus demandés ressemblent à une liste de tous les endroits où un framework peut laisser traîner des secrets : /.env, /app/.env, /api/.env, /backend/.env, /.env.local, /.env.production, /.env.bak, /.aws/credentials. Les faux robots n’ont jamais demandé /robots.txt. Le vrai robot d’Anthropic l’a fait, et n’a jamais demandé de fichier d’identifiants.
- Symantec, via Help Net Security (23 oct.) : un honeypot se faisant passer pour un service d’IA non protégé a surpris l’agent autonome d’un attaquant en pleine action. Son prompt de jailbreak expliquait au modèle que lire des fichiers .env, des clés API et des schémas de base de données relevait du travail de développement ordinaire. La plupart des plus de 127 000 requêtes enregistrées par le honeypot étaient de la reconnaissance, des tentatives avec des clés volées et des sondes à la recherche de fichiers de configuration exposés.
Le schéma est clair. Les attaquants savent que les propriétaires de sites ont commencé à autoriser les robots d’IA, alors ils empruntent leurs noms. Et ils savent que les clés d’IA valent de l’argent : une clé OpenAI, Anthropic ou Gemini qui fuite peut générer une grosse facture avant que vous ne vous en rendiez compte.
Pourquoi c’est important quand on livre vite
La chaîne user agent n’est qu’un en-tête que le visiteur écrit lui-même. Elle ne prouve rien. Si votre hébergement, une règle de CDN ou votre WAF laisse passer les « robots d’IA connus », vous avez peut-être ouvert une porte à exactement ce trafic.
Surtout, ce qui est recherché est une erreur classique des apps livrées à la hâte. Un fichier .env se retrouve dans la racine web parce que le build a copié tout le dossier du projet. Un .env.production.bak traîne après un correctif nocturne. Une image Docker sert /app comme fichiers statiques. Rien de tout cela ne nécessite un exploit sophistiqué. C’est une requête GET, et peu importe au robot que ce soit sa première requête ou sa quatre-vingt-dixième.
Comment vérifier votre app
Commencez par les chemins que les scanners demandent réellement. Lancez la boucle ci-dessous dans un terminal, avec votre propre domaine.
Vous voulez voir 404 ou 403 sur chaque ligne. Un 200 est un problème, mais vérifiez le contenu avant de paniquer : de nombreuses applications monopages renvoient index.html avec un 200 pour n’importe quel chemin inconnu. Lancez curl -s https://yourapp.com/.env | head -5 et regardez ce qui revient. Si vous voyez des lignes KEY=value, considérez chaque secret de ce fichier comme compromis.
for p in .env .env.local .env.production .env.bak .env.old \
app/.env api/.env backend/.env .aws/credentials .git/config; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourapp.com/$p")
echo "$code /$p"
doneTant que vous y êtes, vérifiez les fuites voisines qui livrent les mêmes secrets par un autre chemin :
- Un répertoire .git accessible permet à n’importe qui de reconstruire votre code source, y compris tout .env qui a un jour été commité.
- Les clés présentes dans votre bundle JavaScript n’ont même pas besoin d’un scanner. Ouvrez les DevTools et cherchez sk-, AIza ou key dans le bundle.
- Les source maps en production peuvent livrer votre code source d’origine, commentaires compris.
Vérifiez ensuite vos logs. Cherchez les requêtes vers /.env ou /.aws/credentials. Si l’une d’elles a renvoyé un 200, c’est l’heure de début de votre incident.
Comment corriger
1. Sortez les secrets de la racine web. La vraie solution, c’est que le fichier ne soit tout simplement pas là pour être servi. Les variables d’environnement ont leur place dans les réglages de votre hébergeur (Vercel, Netlify, Railway, Fly et les autres en proposent tous), pas dans un fichier déployé avec vos ressources statiques. Assurez-vous que .env* figure à la fois dans .gitignore et dans .dockerignore.
2. Bloquez les fichiers cachés au niveau du serveur, en filet de sécurité. Pour nginx :
# Deny all hidden files except the ACME challenge path
location ~ /\.(?!well-known) {
deny all;
return 404;
}Pour Apache (.htaccess) :
<FilesMatch "^\.">
Require all denied
</FilesMatch>Pour une app Express qui sert des fichiers statiques, express.static ignore les fichiers cachés par défaut. Ne le contournez pas avec dotfiles: 'allow'.
3. Renouvelez tout ce qui a été exposé. Supprimer le fichier n’annule pas la fuite des clés. Renouvelez chaque secret qui a été accessible, en commençant par les clés de paiement, de base de données et des fournisseurs d’IA. Notre article sur la fuite chez Railway explique comment renouveler les secrets de votre app sans interruption.
4. Ne faites plus confiance au user agent. Si vous laissez passer les robots d’IA à travers un pare-feu ou une limite de débit, vérifiez-les avec les plages d’IP publiées par les entreprises au lieu de vous fier au nom. GreyNoise liste dans son rapport les fichiers JSON officiels d’Anthropic, OpenAI, Google et Perplexity. Cequence donne le même conseil : vérifiez via des requêtes signées, des plages d’adresses publiées ou des intégrations directes.
5. Corrigez vos outils de développement s’ils sont exposés. GreyNoise a aussi vu ces scanners tenter la faille de lecture de fichiers de Vite CVE-2025-30208. Si un serveur de développement Vite est accessible depuis Internet, passez à 6.2.3, 6.1.2, 6.0.12, 5.4.15 ou 4.5.10 ou plus récent, et n’exposez jamais publiquement vos serveurs de développement.
6. Fixez des plafonds de dépenses sur vos clés d’IA. La plupart des fournisseurs d’IA permettent de plafonner les dépenses mensuelles ou de limiter des clés à des projets précis. Cela n’empêche pas une fuite, mais une mauvaise surprise à quatre chiffres devient une petite.
Checklist rapide
Avant de fermer le terminal, vérifiez que :
- chaque chemin de la boucle curl ci-dessus renvoie 404/403, et non votre fichier ;
- .env* figure dans .gitignore et .dockerignore ;
- votre serveur ou hébergeur refuse les fichiers cachés ;
- aucune clé secrète ne se trouve dans le bundle JS ou les source maps ;
- toute clé ayant été accessible a été renouvelée ;
- les listes d’autorisation des robots d’IA vérifient les plages d’IP, pas seulement le user agent ;
- des plafonds de dépenses sont définis sur les clés de vos fournisseurs d’IA.
Vérifiez avant les robots
Ces scanners alternent entre des centaines d’adresses et passent environ huit secondes sur chaque rafale. Ce n’est pas en surveillant vos logs que vous gagnerez. Vous gagnez en vous assurant qu’il n’y a rien à trouver quand ils frappent à la porte.
AppSafe recherche précisément les fuites que traquent ces robots, notamment les fichiers .env accessibles, les répertoires .git exposés, les dumps de base de données et les clés API dans votre bundle frontend, et chaque résultat s’accompagne d’un prompt de correction à copier-coller dans votre outil de code IA. Si vous êtes encore en phase de pré-lancement, notre checklist pour les apps construites avec l’IA est une bonne lecture complémentaire. Lancez un scan gratuit de votre app et voyez ce qu’un robot verrait.