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
