Nel giro di pochi giorni, la Dating App “Tea”, pensata come una piattaforma di sicurezza per donne, ha subito due rilevanti data breach: prima la fuoriuscita di 72.000 immagini (selfie e documenti di verifica), poi l’esposizione di oltre 1,1 milioni di messaggi privati contenenti informazioni particolarmente sensibili. Un disastro per la privacy e un caso emblematico per analisti security e red team.
Primo incidente: immagini e identificativi
Il 25 luglio 2025, Tea ha confermato l’accesso non autorizzato a un sistema di archiviazione legacy contenente dati di utenti registrati prima di febbraio 2024. Sono stati compromessi:
- Circa 13.000 selfie e foto identità.
- Altre 59.000 immagini pubblicate su post, commenti e DM.
L’azienda ha assicurato che email e numeri di telefono non sono stati esposti. Il caso ha evidenziato la criticità di conservare immagini sensibili oltre il tempo necessario, nonostante le policy previste di cancellazione dopo la verifica.
Secondo breach: 1.1 milioni di messaggi compromessi
Pochi giorni dopo, è emerso che il sistema di messaggistica era vulnerabile. Grazie a un accesso API non sufficientemente protetto:
- Sono stati estratti più di 1,1 milioni di DM tra utenti, contenenti dettagli su infedeltà, aborto, abuso, contatti personali e altro.
- A differenza del primo breach — attribuito a dati legacy — qui è coinvolto un sistema ancora attivo, rendendo l’incidente ancora più grave.
Tea ha quindi disattivato temporaneamente il sistema DM, notificato gli utenti e offerto servizi di protezione identità mentre prosegue l’indagine con forze dell’ordine ed esperti esterni.
Vulnerabilità tecniche e failure progettuali
Firebase esposto
Le cause principali del secondo incidente indicano un bucket Firebase non configurato correttamente: accessibile pubblicamente senza autenticazione robusta né controlli su access log o rate limiting.
Legacy systems e codice “vibe coding”
L’infrastruttura ereditaria — mai completamente migrata — ha mantenuto dati sensibili vulnerabili. Errori di coding, automatismi generati da modelli AI senza audit, e architettura discontinua hanno favorito lo sfruttamento da parte di attori maligni.
Per un’app che si vende come protettiva per le donne, l’approccio minimalista nell’archiviazione (rimozione ID) e la criticità dei contenuti raccolti (messaggi più importanti delle immagini) avrebbero richiesto crittografia end-to-end e segregazione dei dati disponibile solo on-device.
Lezioni per la sicurezza applicativa
- Data retention policy trasparente e applicata: foto identità devono essere eliminate immediatamente dopo verifica OK.
- Configurazione sicura di cloud storage: bucket pubblici mai ammessi, autenticazione API rigorosa, logging.
- Segmentazione della rete e segregazione dati: separare legacy/backups da ambienti attivi.
- Crittografia dei dati sensibili, anche at-rest
- Penetration test periodici e audit esterni, anche in ambienti di sviluppo generati dall’AI.
🔍 Ne parliamo sul forum Cybersecurity
Nel nostro forum dedicato alla sicurezza IT e infosec, è aperto un thread sull’incidente Tea:
➡️ “Tea app breach: analisi tecnica del leak di ID, foto e messaggi privati”
Partecipa con il tuo contributo tecnico:
- Hai esperienza con Firebase Security Rules?
- Sai come mitigare bucket pubblici o API insicure?
- Hai esempi simili di breach con leak di messaggistica sensibile?
🧠 Porta i tuoi casi studio o workaround.
💬 Racconta se hai affrontato flussi legacy mai dismessi.
🔧 Sei un pentester? Condividi insight su audit e remediation.
👉 Vai alla discussione nel forum
Sono casi come questo: la cumulatività di errori — da storage legacy esposto a vulnerabilità API — a mettere in evidenza quanto sia cruciale un approccio security-first.
