una app para denunciar a antiguos ligues dejó expuestos los datos personales de todas sus usuarias

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 saliente, con el fin de advertir a otras usuarias sobre actitudes "abusivas, engañosas o tóxicas".

Para suministrar la fiabilidad de las opiniones, la app exigía un proceso de comprobació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 vírico en julio de 2025, alcanzando el número uno en la App Store... y el aumento de usuarios atrajo todavía 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, al punto que tres días posteriormente, 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 parada nivel. Fue, sencillamente, el resultado de una esclavitud 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 frente a uno de los mayores ejemplos recientes de negligencia digital.

Un desarrollador sin preparación

El primer cifra preocupante: la app fue desarrollada por una sola persona con al punto que 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 partida 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 ampliación móvil de Google que incluye servicios como bases de datos en tiempo verdadero y almacenamiento de archivos. Si proporcionadamente Firebase puede ser una opción razonablemente segura, requiere una configuración precisa de reglas de seguridad. Y aquí falló todo:

• Almohadilla de datos en tiempo verdadero sin restricciones: cualquier persona con la URL de la cojín de datos podía conseguir a su contenido. No se aplicaron reglas de autenticación ni permisos diferenciados. Era, fielmente, una cojín 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 conseguir a ellos.
• Partida de criptográfico: a pesar de que Firebase permite resumir tanto la cojín de datos como los archivos almacenados, Tea no activó esta función. Luego, los datos no solo estaban accesibles, sino todavía legibles para cualquiera.

APK sin protección ni ofuscación

Por otra parte de los errores en el backend, el archivo APK (la interpretació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 todavía posibles atacantes— pudieran extraer la dialéctica de funcionamiento de la app, sus llamadas a la cojín 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 llegada mínimamente protegidas, lo que facilitó aún más el llegada no calificado.

Una récipe para el caos

En conjunto, estos errores configuran un decorado que ni siquiera puede calificarse como un "defecto de seguridad": fue una partida total de medidas básicas de protección. Para ilustrar la magnitud del problema:

• El llegada 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 desterrar, entonces, que la app se convirtiera en objetivo inmediato cuando se volvió vírico: era un blanco ligera. La exposición no era preciso... era evitable, pero no se tomaron las precauciones mínimas para evitarla.

¿Y ahora, qué?

Este escándalo deja, al menos, una enseñanza esencia: 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 positivamente los necesita.

Hoy, la plataforma continúa activa tanto en Android como en iOS, pero se enfrenta a un contienda multimillonario por violación masiva de datos.

Imágenes | Marcos Merino mediante IA

En Genbeta | La nueva app miDNI permite admitir el DNI en el móvil. Esto sabemos sobre la seguridad que ofrece