64% of iOS apps with AI expose credentials
Se hai un'app iOS sul tuo telefono che usa l'intelligenza artificiale, c'è una probabilità su due che stia trasmettendo in rete le tue credenziali o qualcosa che non dovrebbe.
Questo è il risultato di una ricerca empirica condotta da un team della Wake Forest University su 444 applicazioni reali, scaricate dall'App Store americano.
Secondo la ricerca, il 64% delle app iOS che integrano modelli LLM espone attivamente le credenziali API nel traffico di rete. Il problema è che chiunque sappia come intercettarlo può usarle.
Come è stata condotta la ricerca?
Il team ha analizzato 444 app con AI integrata, selezionate manualmente da un pool di 1.092 candidate. Per farlo hanno costruito un framework chiamato LLMKeyLens, un sorta di proxy man-in-the-middle installato su un dispositivo iOS fisico che intercetta tutto il traffico HTTPS in uscita mentre l'utente interagisce con le funzionalità AI dell'app.
Il sistema applica regole specifiche per provider, riconosce il prefisso “sk-proj-” delle chiavi di OpenAI, il formato dei parametri query di Google Gemini, e così via, per estrarre le credenziali candidate e validarle attivamente contro le API dei rispettivi provider. Quindi tutto ciò senza aver accesso al codice sorgente o senza decifrare i binari, pratica sulla quale potremmo dedicare diversi articoli, dato che anche le vulnerabilità al reverse engineering stanno aumentando in maniera esponenziale.
Su 444 app analizzate, 282 esponevano credenziali LLM sfruttabili nel traffico di rete, su almeno 10 provider e 5 piattaforme cloud. Il problema ha colpito app in 13 categorie diverse. L'app più popolare tra quelle vulnerabili aveva oltre 2,3 milioni di recensioni, quindi un’app utilizzata da una grande percentuale della popolazione statunitense.
Come escono le credenziali dall’app? Come mai sono vulnerabili?
La ricerca ha identificato tre meccanismi distinti attraverso cui le credenziali finiscono nel traffico intercettabile.
JWT leakage (48% dei casi)
Questo è il pattern più diffuso.
Gli sviluppatori adottano spesso architetture con proxy backend e rilasciano JSON Web Token ai client, ma dimenticano di imporre una scadenza corretta o l'autenticazione. I token intercettati diventano liberamente riproducibili (in pratica, è come stampare un pass VIP per un concerto senza scriverci sopra la data e senza controllare il documento all'ingresso: se qualcuno te lo ruba, può entrare al posto tuo in qualsiasi momento e spacciarsi per te).
Tra i casi documentati: token con claim di scadenza a 100 anni, token senza campo “exp” (campo di scadenza), server che accettavano token 128 giorni dopo la scadenza dichiarata. Delle vere e proprie scelte architetturali sbagliate che nessuno ha rivisto, e che probabilmente sono state realizzate interamente in vibe coding.
Proxy backend non autenticato (33% dei casi)
Lo sviluppatore fa la cosa giusta, sposta la chiave API grezza su un server proxy lato server. Ma dimentica di implementare il controllo degli accessi sull'endpoint del proxy stesso, creando un relay aperto (un sistema che riceve un messaggio o una richiesta da qualcuno e la passa a qualcun altro per conto suo) che chiunque può sfruttare senza credenziali (in pratica, è come aver preso la chiave di casa e averla data a un maggiordomo privato, che però dimentica di vedere chi bussa alla porta: il maggiordomo continuerà ad aprire a chiunque si presenti, usando la chiave per farli entrare a tue spese).
Un caso documentato dalla ricerca: una Google Cloud Function che accettava POST completamente non autenticati, restituiva risposte generate dall'LLM fatturate sull'account OpenAI dello sviluppatore, ed era rimasta completamente aperta 90 giorni dopo la disclosure responsabile.
Trasmissione in chiaro della API key (19% dei casi)
Questa è sicuramente la forma più grave di tutte: le chiavi API sono embedded direttamente negli header HTTP o nei parametri URL in chiaro. Una singola request intercettata garantisce accesso illimitato all'intero account del provider LLM dello sviluppatore. Nel 52% di questi casi, i system prompt proprietari erano esposti nella stessa request body. Questo è un vero e proprio scenario bizzarro, e un’app su cinque è un numero terribilmente alto, quello che speriamo è che quantomeno abbiano messo un limite superiore alla fatturazione giornaliera o settimanale.
Il caso Baudr: vibe coding e GDPR
Grenbaud, è uno degli streamer italiani più seguiti con oltre un milione di follower su Twitch. Il 14 marzo 2026 ha lanciato Baudr, una piattaforma costruita interamente con l'AI per circa 40 euro, presentata come un social network per trovare persone con interessi simili all'interno della sua community.
Nonostante fosse presentata come una piattaforma per fare amicizia, l'architettura di Baudr era identica a quella di una qualsiasi app di dating: profili con foto, bio, interessi, sistema di match e chat privata. I dati raccolti includevano Twitch ID, foto personali, nome, età, città, segno zodiacale, hobby, preferenze musicali, canali YouTube seguiti, username Instagram e messaggi privati.
A poche ore dal lancio, alcuni utenti hanno scoperto che il pannello di amministrazione della piattaforma era accessibile a chiunque scrivesse "/admin" nella barra del browser. Cosa ha implicato: account cancellati in massa, incluso quello dello stesso Grenbaud, che ha perso il controllo della piattaforma e ha esposto i dati di migliaia di utenti. Lo streamer ha confermato l'incidente dicendo agli utenti: "Alle ragazze a cui ho scritto, se vi sono arrivati messaggi strani da me non sono io."
Dal punto di vista del GDPR, il titolare del trattamento ha 72 ore dalla scoperta per notificare una violazione al Garante Privacy, altrimenti la pena è di sanzioni aggiuntive. Il GDPR impone che i dati personali siano trattati garantendo un'adeguata sicurezza mediante misure tecniche e organizzative. Grenbaud aveva scritto nero su bianco nelle policy che la sicurezza del database non era garantita al 100%, rischiando di consegnare al Garante la prova documentale che il titolare fosse consapevole delle possibili vulnerabilità.
Le sanzioni GDPR arrivano fino al 4% del fatturato annuo o fino a 20 milioni di euro, a seconda di quale sia il valore maggiore.
Questa è la dimostrazione pratica di cosa succede quando si porta in produzione, con utenti reali e dati reali, un'applicazione costruita senza considerare la sicurezza.
Le difese esistono ma quasi nessuno le usa correttamente
Solo il 32% delle app analizzate ha implementato qualche forma di meccanismo anti intercettazione. Tra quelle che lo hanno fatto, l'HTTP proxy bypass era la difesa più comune, ma portava un tasso di bypass dell'81% quando contrastata dal fallback VPN-layer di LLMKeyLens.
Le difese multi-layer, quelle che combinano proxy bypass con cifratura custom del payload o canali WebSocket, riducevano il tasso di bypass quasi a zero. Ma solo il 30% delle app protette aveva adottato queste strategie combinate.
Il che significa che anche tra chi ci ha provato, la maggioranza lo ha fatto in modo insufficiente.
Il dato ancora più clamoroso è che quasi nessuno sistema
La ricerca ha seguito il protocollo di responsible disclosure standard: tutte le 282 vulnerabilità sono state segnalate agli sviluppatori tramite i canali App Store, con una finestra di 90 giorni per rimediare.
Dopo tre mesi, solo il 28% delle app vulnerabili aveva risolto il problema. Il restante 72% era ancora sfruttabile. Tra queste:
• 36 app avevano proxy backend non autenticati dove la disclosure da sola non aveva spinto le modifiche architetturali necessarie;
• 30 app avevano implementazioni JWT fondamentalmente difettose che non erano state toccate.
Perché succede?
La ricerca mette in risalto un problema che non dipende soltanto dagli sviluppatori. I provider LLM, OpenAI, Anthropic, Google Gemini, non documentano esplicitamente l'integrazione client-side come pattern insicuro, quindi chi vibe coda si imbatte in questa sorta di errori da parte degli LLM. Le reference implementation di architetture proxy autenticate non esistono o sono difficili da trovare, inoltre Apple non esegue analisi dinamica del traffico prima di approvare le app sull'App Store.
Quindi migliaia di sviluppatori (o LLM) prendono la strada più semplice, mettere la chiave nell'app.
Come proteggersi se sviluppi app iOS con LLM
Se stai costruendo un'app iOS che integra modelli AI, queste sono le pratiche che separano un'implementazione sicura da una vulnerabile:
• routing server-side obbligatorio: tutte le chiamate alle LLM API devono passare attraverso un proxy autenticato lato server, la chiave API non deve mai uscire dal backend;
• controllo degli accessi sul proxy: non basta spostare la chiave sul server, ma bisogna imporre autenticazione su ogni endpoint del proxy, altrimenti si crea un relay aperto equivalente a non avere il proxy;
• JWT con scadenza breve e revoca: se vengono usati token per autenticare i client, bisogna sempre impostare TTL brevi, mai superiori a qualche ora, e implementare la revoca immediata in caso di compromissione;
• credenziali effimere: le credenziali di accesso al proxy devono avere una durata limitata e rotazione automatica. Una credenziale compromessa deve essere inutilizzabile nel tempo più breve possibile;
• anomaly detection: considerare alert su volumi di richieste anomali per singola chiave. Una chiave usata da migliaia di client distinti in poche ore è un segnale chiaro;
• non esporre i system prompt: se l’app ha un system prompt proprietario, non deve mai apparire nel body delle request che escono dal client, ma deve restare sempre sul server.
La prospettiva di uno sviluppatore iOS
Sono uno sviluppatore iOS, quello che posso dire è che questa ricerca conferma qualcosa che chi lavora nel settore sospettava già, ovvero che la corsa alla feature AI e alle app vibe codate ha bruciato le tappe sulla sicurezza informatica.
Quando un nuovo SDK LLM esce con una documentazione che mostra come fare la prima call in tre righe di codice direttamente dal client, è ovvio che molti sviluppatori o llm partano da lì. Il problema è che quella dimostrazione veloce non è mai pensata per finire direttamente in produzione, ma purtroppo molte volte ci finisce.
Bisognerebbe trattare le chiavi LLM con attenzione critica, come una qualsiasi altra api key, e bisognerebbe almeno, se si vibe coda, preoccuparsi quantomeno di chiedere all’llm di prestare attenzione alla sicurezza dei dati e delle chiavi, facendosi spiegare per bene l’architettura.
Cosa dovrebbe cambiare nel sistema
La ricerca chiama in causa tre attori oltre agli sviluppatori individuali:
• I provider LLM dovrebbero documentare esplicitamente che l'integrazione client-side diretta è un pattern insicuro, pubblicare architetture di riferimento per proxy autenticati, e introdurre anomaly detection per flaggare chiavi usate da volumi anomali di client distinti;
• Apple potrebbe integrare strumenti di analisi dinamica del traffico nel processo di review dell'App Store per rilevare l'esposizione delle credenziali a livello di trasmissione prima che le app vengano approvate pubblicamente;
• Gli sviluppatori devono smettere di trattare la security come un problema da risolvere dopo il lancio. Con il 72% delle vulnerabilità ancora aperte 90 giorni dopo la segnalazione, è chiaro che nemmeno chiedere di rimediare funziona.
Conclusione
Il 64% delle app iOS AI-powered che espone credenziali LLM è il risultato di un ecosistema che ha accelerato l’adozione AI senza costruire le basi di sicurezza necessarie.
Se sviluppi app mobile o web con integrazione LLM, e non hai mai fatto un audit della sicurezza delle tue implementazioni, il momento è ora, prima che qualcuno usi la tua chiave per generare milioni di token a tue spese.
Fonti: Wake Forest University, Arxiv (2606.12212), Cyberpress. Il caso Baudr è stato documentato pubblicamente dallo stesso Grenbaud durante le sue live su Twitch e da diverse analisi indipendenti pubblicate online.