Deux tiers des applis iOS d'IA laissent fuir leurs identifiants LLM en clair

De quoi s’agit-il ?

Le 10 juin 2026 (version révisée le 23 juin), des chercheurs de l’université Wake Forest ont publié Mind your key, la première étude empirique approfondie sur la fuite d’identifiants d’API LLM dans les applications iOS (arXiv:2606.12212). Ils ont constitué un jeu de 444 applications de chatbot IA, filtrées à partir de 1 092 candidates sur l’App Store américain, et inspecté le trafic réseau de chacune avec un outil maison baptisé LLMKeyLens. Le constat : 282 des 444 applications — près des deux tiers — exposent des identifiants LLM exploitables qui permettent à n’importe qui d’envoyer des requêtes au modèle sur le compte du développeur, lequel paie la facture.

Ce qui rend le résultat gênant, c’est le peu d’effort qu’exige l’extraction. LLMKeyLens n’a besoin ni du code source ni du déchiffrement du binaire ; il se contente d’observer le trafic déjà émis par l’application et d’en extraire le secret au passage. Les identifiants couvrent au moins dix fournisseurs, OpenAI en tête, et treize catégories d’applications.

Comment ça marche

Lorsqu’une application mobile embarque une clé de fournisseur pour appeler directement un service comme OpenAI ou Gemini, cette clé voyage avec chaque requête émise. Quiconque observe le trafic — l’utilisateur de l’application, une personne sur le même réseau ou un proxy — peut la lire. L’étude classe les 282 applications fuyardes en trois schémas.

Le plus répandu, à 48 % (136 applications), est la fuite de jetons rejouables. Ces applications font le choix théoriquement plus sûr de distribuer des jetons éphémères plutôt que la clé brute, mais les jetons fuient dans le même trafic et étaient généralement encore valides une fois capturés. Certains n’avaient rien d’éphémère : une application populaire fixait l’expiration de son jeton à l’an 2125 — soit un laissez-passer de cent ans — et le jeton « d’une heure » d’une autre fonctionnait encore 128 jours après sa mort supposée.

Le deuxième schéma, 33 % (92 applications), est le backend proxy non authentifié : l’application achemine ses requêtes via un serveur qui répond à tout le monde, sans vérifier qui demande. C’est un relais ouvert vers un compte IA payant, et il n’y a aucune clé à voler puisqu’aucune n’est requise.

Le troisième, 19 % (54 applications), est la transmission de clé en clair — la clé brute du fournisseur envoyée à découvert, lisible dans une seule requête capturée. Pour 28 de ces 54 applications, la même requête révélait aussi le prompt système caché, exposant les instructions coulisses du produit en même temps que son identifiant de facturation.

Pourquoi c’est important

Une clé LLM qui fuit n’est pas un risque abstrait : c’est un risque compté au jeton. Les clés volées alimentent la pratique que l’industrie appelle LLMjacking, et Sysdig a estimé une consommation dans le pire des cas à plus de 46 000 $ par jour de charges modèle sur un seul compte compromis. Au-delà de la facture, un proxy ouvert ou une clé exposée offre à un attaquant de l’inférence gratuite sur un modèle de pointe, et un prompt système divulgué peut révéler une logique propriétaire et suggérer d’autres pistes d’abus.

Le pire, c’est la persistance. Les chercheurs ont prévenu les 282 développeurs et attendu trois mois ; seules 28 % avaient clairement corrigé le problème, 23 % restaient grandes ouvertes avec l’accès fuité toujours fonctionnel, et le reste était hors ligne ou renvoyait des erreurs. Cela fait écho aux constats antérieurs sur Android — l’étude LM-Scout de 2025 s’était introduite automatiquement dans 120 applications via la même classe de câblage non sécurisé. L’engouement pour l’IA n’a donc pas changé l’habitude, il en a seulement relevé le coût. Les auteurs insistent : le chiffre des deux tiers est un plancher ; beaucoup d’applications bloquaient purement l’interception, et l’étude ne couvrait que l’App Store américain fin 2025.

Défenses

Le correctif de fond est un vieux conseil que trop d’équipes ignorent : la clé du fournisseur ne doit jamais résider dans le client.

• Faites transiter chaque appel modèle par votre propre backend. L’application parle à votre serveur ; votre serveur détient la clé du fournisseur et parle à OpenAI, Gemini et les autres. La clé ne part jamais dans le binaire ni sur le fil vers l’appareil.
• Authentifiez l’appelant sur ce backend. Un relais qui répond à tout le monde est un relais ouvert. Rattachez chaque requête à une identité d’utilisateur ou d’appareil authentifiée et rejetez le reste.
• Émettez des jetons réellement éphémères et cadrés. Imposez une expiration réelle côté serveur, liez les jetons à un utilisateur et à un usage, et rejetez les jetons expirés ou rejoués plutôt que de faire confiance à une horloge fournie par le client.
• Ajoutez des plafonds de dépense, des quotas par utilisateur et des limites de débit. Ils bornent les dégâts quand un identifiant fuit et laissent le temps de réagir.
• Surveillez les anomalies et révoquez vite. Une clé qui dessert soudain des milliers d’appareils est un signal. Faites tourner les clés à la moindre suspicion — et vérifiez que l’ancienne est bien révoquée, car les audits antérieurs ont montré que les développeurs laissent souvent actives des clés pourtant retirées.

L’étude place aussi une part de responsabilité en amont : elle demande aux fournisseurs de signaler les clés côté client comme non sûres dans leur documentation et de repérer les clés utilisées depuis un nombre invraisemblable d’appareils, et elle demande à Apple de dépister ce schéma lors de la revue App Store.

Statut

Élément	Valeur (Wake Forest, juin 2026)
Applications analysées	444 (filtrées depuis 1 092)
Applications laissant fuir des identifiants exploitables	282 (~64 %)
Fuite de jetons rejouables	48 % (136 applications)
Backend proxy non authentifié	33 % (92 applications)
Transmission de clé en clair	19 % (54 applications)
Applis en clair exposant aussi le prompt système	28 sur 54
Fournisseurs touchés	≥ 10 (OpenAI en tête)
Corrigé 3 mois après signalement	28 %
Encore exploitable au re-test	23 %
Outil de détection	LLMKeyLens (interception du trafic, sans déchiffrement du binaire)

Dates clés : 10 juin 2026 — première soumission de l’étude. 23 juin 2026 — version révisée. 30 juin 2026 — reprise médiatique. Réserve de périmètre : App Store américain, fin 2025 ; le taux des deux tiers est une borne basse.