Tea era una aplicación que prometía ser un «espacio seguro para las mujeres»: permitía que éstas publicasen reseñas anónimas sobre hombres con los que habían salido, con el fin de advertir a otras usuarias sobre actitudes «abusivas, engañosas o tóxicas».
Para mantener la fiabilidad de las opiniones, la app exigía un proceso de verificación riguroso: se solicitaban selfies, identificaciones oficiales (como carnets de conducir) y otra información personal extremadamente sensible.
Pero la seguridad de un espacio no la proporcionan meramente las buenas intenciones. La app se hizo viral en julio de 2025, alcanzando el número uno en la App Store… y el aumento de usuarios atrajo también atención indeseada: la de los hackers.
Eso quizá no hubiera importado demasiado si la app no hubiera resultado estar diseñada de forma escalofriantemente chapucera. ¿Resultado? Ha terminado exponiendo información privada de miles de usuarias.
En cuestión de días, se produjeron dos filtraciones devastadoras. La primera, el 25 de julio, reveló documentos oficiales, imágenes privadas y datos de geolocalización de usuarias previos a 2024.
La segunda, apenas tres días después, expuso mensajes recientes con contenido extremadamente sensible: desde conversaciones sobre infidelidades hasta abortos. Peor aún, en foros como 4Chan comenzaron a circular mapas precisos con la ubicación de las usuarias.
¿Cómo fue esto posible?
Un desastre técnico de proporciones épicas
Resulta que la filtración masiva de datos de Tea no fue producto de un sofisticado ataque de ciberespionaje ni de una intrincada operación de hackers de alto nivel. Fue, sencillamente, el resultado de una cadena de errores técnicos elementales cometidos por desarrolladores inexpertos.
El ingeniero de software Jan Kammerath, tras analizar en su blog el código fuente de la aplicación, ha dejado claro que nos encontramos ante uno de los mayores ejemplos recientes de negligencia digital.
Un desarrollador sin preparación
El primer dato alarmante: la app fue desarrollada por una sola persona con apenas seis meses de experiencia en programación. Esta información fue confirmada por el propio perfil de LinkedIn del creador, lo que ya anticipaba la ausencia de buenas prácticas, de revisión por pares o de pruebas de seguridad rigurosas.
Firebase mal configurado: la puerta abierta al desastre
Tea utilizaba Firebase, una plataforma de desarrollo móvil de Google que incluye servicios como bases de datos en tiempo real y almacenamiento de archivos. Si bien Firebase puede ser una opción razonablemente segura, requiere una configuración precisa de reglas de seguridad. Y aquí falló todo:
- Base de datos en tiempo real sin restricciones: cualquier persona con la URL de la base de datos podía acceder a su contenido. No se aplicaron reglas de autenticación ni permisos diferenciados. Era, literalmente, una base de datos pública camuflada tras una interfaz privada.
- Almacenamiento de archivos expuesto: identificaciones oficiales, selfies, documentos personales y otros archivos privados se guardaban en Firebase Storage… sin ningún sistema de autenticación. Bastaba conocer (o adivinar) la URL para acceder a ellos.
- Ausencia de cifrado: a pesar de que Firebase permite cifrar tanto la base de datos como los archivos almacenados, Tea no activó esta función. Por tanto, los datos no solo estaban accesibles, sino también legibles para cualquiera.
APK sin protección ni ofuscación
Además de los errores en el backend, el archivo APK (la versión instalable de Android) no estaba ofuscado, lo que significa que el código fuente era fácilmente accesible y comprensible. Esto permitió que investigadores —y también posibles atacantes— pudieran extraer la lógica de funcionamiento de la app, sus llamadas a la base de datos, sus rutas de almacenamiento, y toda su estructura interna.
El APK contenía información sensible incrustada, como endpoints de Firebase y claves de acceso mínimamente protegidas, lo que facilitó aún más el acceso no autorizado.
Una receta para el caos
En conjunto, estos errores configuran un escenario que ni siquiera puede calificarse como un «fallo de seguridad»: fue una ausencia total de medidas básicas de protección. Para ilustrar la magnitud del problema:
- El acceso a los datos no requería login ni token de sesión.
- Los usuarios maliciosos podían modificar datos desde fuera de la app.
- La estructura del backend no contaba con ningún sistema de control de roles o permisos.
- Cualquier persona con un nivel medio de conocimientos podía automatizar el scraping masivo de fotos, nombres, ubicaciones y conversaciones.
No es de extrañar, entonces, que la app se convirtiera en objetivo inmediato cuando se volvió viral: era un blanco fácil. La exposición no era inevitable… era evitable, pero no se tomaron las precauciones mínimas para evitarla.
¿Y ahora, qué?
Este escándalo deja, al menos, una enseñanza clave: no toda app merece nuestra confianza. Que una app esté en las tiendas oficiales no garantiza que sea segura. Debemos analizar qué datos solicita y si realmente los necesita.
Hoy, la plataforma continúa activa tanto en Android como en iOS, pero se enfrenta a un litigio multimillonario por violación masiva de datos.
Imágenes | Marcos Merino mediante IA
En Genbeta | La nueva app miDNI permite llevar el DNI en el móvil. Esto sabemos sobre la seguridad que ofrece
–
La noticia
El código era una chapuza: una app para denunciar a antiguos ligues dejó expuestos los datos personales de todas sus usuarias
fue publicada originalmente en
Genbeta
por
Marcos Merino
.
