El rastreo
La firma de seguridad UpGuard publicó el viernes una investigación en la que rastreó unos 300.000 dominios con indicios de Supabase, extraídos de datos tecnográficos de BuiltWith y de los conjuntos del Chrome UX Report en BigQuery, y consultó en cada uno una tabla users.
Encontró 16.326 bases de datos en las que al menos algunas tablas podían ser leídas por cualquiera. Más de la mitad mostraban indicios de información personal identificable. Un número menor mostraba contraseñas o tokens de autenticación, y una cantidad muy pequeña, lo que parecían datos de tarjetas.
Qué había dentro
Los ejemplos son concretos. Una plataforma india dejó expuestos 65.467 usuarios con nombres, correos, fechas de nacimiento, datos de permiso de conducir, pasaporte y Aadhaar, además de información financiera. Un servicio de códigos de un solo uso en Filipinas expuso más de 2.000 usuarios y más de 100.000 mensajes SMS, incluidos los propios códigos. Un servicio estadounidense de aparcacoches expuso más de 100.000 clientes con teléfonos, correos y matrículas.
El consulado de un gobierno africano expuso 25.000 registros con direcciones de poblaciones vulnerables. Un servicio canadiense de inmigración y mudanzas expuso 5.000 registros, 884 de ellos con contraseñas guardadas en texto plano. UpGuard también halló infraestructura ligada a una granja de SIM virtuales usada para interceptar los códigos de un solo uso que verifican cuentas en línea: el lado de la oferta del fraude de suplantación de cuentas, al descubierto.
La mayoría de los conjuntos expuestos parecen estar en Estados Unidos, pero UpGuard describe el problema como mundial y señala que las regiones con mejor práctica de protección de datos dieron mejores resultados.
El valor por defecto que no lo es
El mecanismo que identifica UpGuard es estrecho y concreto. “Las tablas creadas de forma programática a través de la API, que es como los agentes de programación interactúan con Supabase, no habilitan RLS por defecto”, escribe. La seguridad por fila es el control que decide qué filas puede leer cada solicitante; sin ella, una tabla accesible desde internet es legible.
Eso importa por quién está creando las tablas. Supabase alcanzó una valoración de 10.000 millones de dólares este año gracias a los desarrolladores que alojan aplicaciones hechas con vibe coding, como señala TechCrunch. Quien dirige a un agente de programación no es necesariamente alguien que sepa qué es la seguridad por fila, y menos aún que la ruta que tomó su agente se la saltó.
La respuesta de Supabase
El director de seguridad de la información de Supabase, Bil Harmer, dijo a TechCrunch que la compañía no había visto la investigación y que sus proyectos son “seguros por defecto”. Planteó la seguridad como una responsabilidad compartida: “Proporcionamos valores por defecto y herramientas seguros, y los clientes controlan cómo se configuran sus propios proyectos”, y dijo que la empresa avisa a los clientes afectados cuando detecta problemas.
“La seguridad en Supabase nunca está terminada. Nos importa mucho hacerlo bien y seguiremos facilitando que cada desarrollador publique de forma segura”, dijo Harmer.
Ambas afirmaciones pueden ser ciertas a la vez, y ahí está lo incómodo. La ruta del panel puede muy bien ser segura por defecto mientras la de la API no lo es, y la de la API es la que usan los agentes.
Qué cerraría el agujero
El arreglo no es un misterio: habilitar la seguridad por fila en las tablas creadas por la API, o negarse a servirlas públicamente hasta que exista una política. Esa es una decisión de plataforma y no del cliente, y es la decisión que conviene vigilar. Hasta que se tome, la cifra es un suelo y no un techo: UpGuard buscó un nombre de tabla, en dominios que pudo identificar, en un momento dado.
