16.326 bases de datos de Supabase abiertas a cualquiera: cómo la programación con IA extiende un viejo error

Leer al menos una tabla de cada una de 16.326 bases de datos de Supabase solo exigía la clave que la web entrega a cada visitante, sin contraseña. Es el recuento que la empresa de ciberseguridad UpGuard publicó el 25 de septiembre de 2026 tras sondear unos 300.000 dominios con indicios de usar Supabase. Según su informe, más de la mitad de esas bases mostraban indicios de datos personales, y una parte menor guardaba contraseñas o tokens de autenticación.

Supabase es un servicio gestionado que reúne la parte de servidor de una aplicación (base de datos PostgreSQL, autenticación y una API generada automáticamente), y muchos asistentes de programación con IA lo eligen para poner en marcha una aplicación en pocas horas.

No hay un fallo de la plataforma que parchear. Quién lee qué lo decide la configuración de cada proyecto, en especial la seguridad a nivel de fila (RLS, por sus siglas en inglés), la función de PostgreSQL que limita qué filas de cada tabla puede ver cada usuario. El calendario obliga a revisarla ahora: el 30 de octubre, Supabase dejará de publicar automáticamente en su API las tablas nuevas de los proyectos existentes. Su anuncio aclara que las tablas que ya existen conservan sus permisos y siguen accesibles.

¿Cuántas bases de datos de Supabase están expuestas?

UpGuard contó al menos 16.326 bases de datos de Supabase con tablas legibles sin contraseña. Su equipo de investigación, dirigido por Greg Pollock, localizó las webs con Supabase cruzando datos de BuiltWith y del Chrome UX Report con el análisis del JavaScript de cada página. En cada una consultó la tabla de usuarios y, para clasificar las bases, dedujo del esquema qué tipo de datos contenían, sin leer todas las filas. Después examinó a fondo un puñado de casos y, cuando detectó una exposición grave, avisó al propietario de la aplicación.

El informe describe, sin nombrarlos, ejemplos como estos:

• Un servicio de aparcacoches estadounidense que exponía datos de más de 100.000 clientes: el teléfono de todos, la matrícula de unos 78.000 y el historial de visitas.
• El consulado de un gobierno africano con datos personales y direcciones de 25.000 personas, entre ellas el alojamiento de emergencia en el que residían.
• Un servicio de asesoramiento para quienes emigran a Canadá, con casi 5.000 fichas de usuarios; 884 guardaban la contraseña en texto claro, cifra que también recoge BleepingComputer.
• Una plataforma india de contenidos que exponía datos de 65.467 usuarios, información de pago y más de 100.000 mensajes privados.

El método tiene límites. Si una base no tenía tabla de usuarios, la propia API sugería el nombre de otra tabla legible, pero el estudio solo abarca los dominios que BuiltWith y el Chrome UX Report permitieron identificar, y UpGuard cree que ampliar la búsqueda daría con más casos. Es razonable leer la cifra como un mínimo.

UpGuard añade una lectura geográfica. Atribuye a la normativa europea de protección de datos un efecto favorable sobre las prácticas de las empresas y observa más fugas en las regiones en desarrollo.

Tres investigaciones anteriores con el mismo diagnóstico

UpGuard no es el primero en llegar a esta conclusión. Entre mayo de 2025 y febrero de 2026, otros tres trabajos, con métodos distintos, dieron con el mismo problema.

Lovable, mayo de 2025

El investigador Matt Palmer publicó la vulnerabilidad CVE-2025-48757, que describe políticas de seguridad a nivel de fila insuficientes en muchos proyectos generados con Lovable, una plataforma que crea aplicaciones a partir de instrucciones en lenguaje natural. En su comunicado posterior detalla 303 puntos de acceso vulnerables de la API en 170 de los 1.645 proyectos analizados, el 10,3 %. Lovable había añadido en abril un análisis de seguridad que, según Palmer, comprobaba que hubiera políticas pero no que fueran correctas.

Escape, octubre de 2025

La empresa de seguridad Escape revisó más de 5.600 aplicaciones públicas creadas con Lovable, Base44, Create.xyz, Vibe Studio y Bolt.new, sin ir más allá de lo que vería un visitante. Contabilizó más de 2.000 vulnerabilidades, más de 400 secretos expuestos y 175 casos de datos personales accesibles, con historiales médicos e IBAN entre ellos. Entre los patrones que describe está el de la aplicación que lleva en su JavaScript una credencial anónima y con ella consulta directamente la API de la base de datos.

Wiz, febrero de 2026

La empresa de seguridad en la nube Wiz documentó el caso de una red social para agentes de IA, construida con asistentes de código, que llevaba la clave de Supabase en el JavaScript del cliente y no tenía activada la seguridad a nivel de fila. La base admitía lectura y escritura y contenía 1,5 millones de credenciales de API, unas 35.000 direcciones de correo y 4.060 conversaciones privadas. Tras el aviso, la corrección llevó unas tres horas.

Escape encontró además fallos de otros tipos, pero el hilo común de los cuatro trabajos es modesto: una base de datos que respondía a quien preguntara, sin intrusión sofisticada de por medio.

¿Qué ha cambiado desde el caso Lovable?

Supabase ha ido endureciendo su configuración por defecto. Según la empresa, desde 2025 las tablas creadas en el panel web activan por sí solas la RLS. Las que se crean mediante SQL o la API no la activan, salvo que el proyecto tenga configurado un disparador de eventos que lo haga, y la API es, según UpGuard, la vía habitual de los agentes de programación.

El 28 de abril de 2026, la empresa anunció un cambio más profundo: las tablas nuevas del esquema public (el predeterminado) dejan de publicarse automáticamente en su API de datos y en la de GraphQL, y hay que concederles acceso de forma explícita con GRANT. Es el comportamiento por defecto de los proyectos nuevos desde el 30 de mayo y lo será en los existentes desde el 30 de octubre. El anuncio lo justifica así: hoy también crean tablas agentes, scripts de línea de comandos y plataformas de IA, a menudo sin que una persona revise el cambio.

También están cambiando las claves. Supabase sustituye las antiguas anon y service_role por claves publicables (sb_publishable_) y secretas (sb_secret_) y, según su documentación, declarará obsoletas las anteriores a finales de 2026.

También ha cambiado el perfil de quien construye estas aplicaciones. Hace un año el foco estaba en plataformas pensadas para quien no programa. UpGuard señala ahora que Supabase es la base de datos que más recomienda Claude Code, el agente de programación de Anthropic, y que los agentes de programación en general tienden a proponerla. Una herramienta montada así por un departamento puede apoyarse en una base de datos de producción con información de clientes que el departamento de sistemas desconoce.

¿Es segura la clave publicable (anon key) de Supabase?

Sí, siempre que la RLS esté bien configurada: la clave publicable (la antigua anon key) está hecha para exponerse, y lo que protege los datos son las políticas de la base de datos. En una aplicación con Supabase, el navegador habla directamente con la base de datos a través de PostgREST, el servicio que genera automáticamente una API REST a partir del esquema. Para hacerlo lleva la dirección del proyecto y la clave publicable, que la documentación de Supabase considera segura en una página web o en el código fuente.

Esa clave equivale al rol anon de PostgreSQL (el rol authenticated procede del inicio de sesión de cada usuario, no de la clave), y las políticas de RLS deciden qué filas ve cada rol. Si la RLS está desactivada en una tabla publicada, el rol anon la lee entera. Si está activada con una política que admite todas las filas para ese rol, el efecto es el mismo, y un análisis que solo compruebe si la RLS está encendida da la tabla por buena.

Con las claves secretas ocurre lo contrario. Se saltan la RLS, y la documentación advierte de que una clave secreta filtrada expone todos los datos del proyecto. Encontrar una en el JavaScript de una web sí es una fuga, y obliga a retirarla y sustituirla cuanto antes.

Para los equipos de seguridad, la consecuencia es de arquitectura. El control reside en la base de datos, y ni el perímetro ni el código del cliente lo sustituyen. El rastro de un acceso indebido queda en los registros de la puerta de enlace de la API mientras se conservan: peticiones con la clave publicable que devuelven tablas completas.

¿Cómo comprobar si una base de datos de Supabase está expuesta?

Se comprueba en dos frentes: localizar todas las aplicaciones de la empresa que usan Supabase y verificar, en cada una, qué devuelve la API a un visitante anónimo y a un usuario recién registrado.

Lo que sigue funcionando

El inventario va primero. Muchas de estas aplicaciones son shadow IT en estado puro, y hay que buscarlas desde dos lados. Desde fuera, rastreando los dominios y subdominios de la empresa cuyo JavaScript llama a proyectos de Supabase; un programa de gestión de la superficie de ataque externa puede automatizar esa parte. Desde dentro, revisando las suscripciones a Supabase pagadas con tarjeta corporativa y preguntando a los departamentos que desarrollan con IA.

Después hay que aplicar el mínimo privilegio dentro de la base de datos. En cada proyecto localizado, esta consulta de solo lectura sobre el catálogo de PostgreSQL muestra qué tablas del esquema public tienen la RLS desactivada:

select schemaname, tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

La consulta no cubre las vistas, que en Supabase se saltan la RLS por defecto porque se ejecutan con los privilegios de su propietario, así que hay que revisarlas aparte. El asesor de seguridad del panel de Supabase señala esos casos y otros afines, como políticas demasiado permisivas o columnas sensibles expuestas; los explica su guía de asesores. Los proyectos existentes pueden adoptar ya los permisos explícitos mediante GRANT, sin esperar al 30 de octubre.

Mientras una política no se prueba, no se sabe si funciona. La comprobación tiene dos partes: consultar la API solo con lo que la página entrega al navegador, como haría un visitante anónimo, y repetir la consulta con un usuario de prueba recién registrado, porque muchas aplicaciones admiten el registro libre. En ambos casos, la API debe devolver solo lo previsto. Esta prueba puede incorporarse al ciclo de DevSecOps o cubrirse en una auditoría de seguridad de API.

Los supuestos que han caducado

• Tratar como incidente una clave visible en el código que descarga el navegador. Si es la publicable, lo relevante es qué devuelve la base de datos a quien la usa.
• Limitar la revisión al código que escribe el asistente. La configuración que abre la base se crea con órdenes SQL que ejecuta el agente y que pueden no quedar en el repositorio.
• Dar por buena una casilla marcada: si la política deja leerlo todo, tener la RLS encendida no protege la tabla.
• Confiar en que el cambio del proveedor arregla el pasado, cuando las tablas que existan el 30 de octubre conservarán sus permisos.

Si quien construye estas aplicaciones para la empresa es un proveedor, la forma en que controla el acceso a su base de datos gestionada debería figurar en el cuestionario de riesgo de terceros.

Si una tabla estuvo abierta, ¿hay que notificar?

La obligación de notificar depende de qué datos contenía la tabla y de lo que se pueda demostrar sobre los accesos. Una tabla con datos personales legible sin autenticación puede constituir una brecha de seguridad que afecta a la confidencialidad, y si no hay registros que prueben que nadie la leyó, la exposición en sí ya pesa en la evaluación.

En ese caso, el artículo 33 del RGPD exige notificarla a la autoridad de control sin dilación indebida y, si es posible, en un máximo de 72 horas desde que se tiene constancia, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas. Si el riesgo es alto, como cuando quedan expuestas contraseñas, el artículo 34 obliga además a comunicarlo a los afectados. En un artículo anterior repasamos cómo trató la Agencia Española de Protección de Datos una brecha atribuida a un agente de IA.

Para distinguir entre «expuesta» y «leída» se necesitan los registros de la puerta de enlace y de PostgREST, y su conservación depende del plan contratado: un día en el plan gratuito, siete en Pro, 28 en Team y 90 en Enterprise. Lo prudente es cerrar la tabla y, en paralelo, exportar esos registros cuanto antes.

Lo que queda por ver

Desde el 30 de octubre, las tablas nuevas del esquema public nacerán cerradas a la API en todos los proyectos, y es previsible que aparezcan menos bases abiertas. UpGuard compara la situación con Amazon S3 y GitHub, dos servicios con configuraciones pensadas para la comodidad que acumularon años de filtraciones. A nuestro juicio, Supabase ha corregido sus valores por defecto antes en su trayectoria que aquellos servicios, y lo ha hecho pensando expresamente en los agentes.

La incógnita es qué hará un agente cuando la tabla que acaba de crear no aparezca en la API: si pedirá el permiso justo o el que antes haga funcionar la aplicación. Hasta entonces, cada GRANT que ejecute un agente debería pasar la misma revisión que un cambio de permisos hecho por una persona.

Sobre los riesgos del desarrollo asistido por IA en la empresa, véase nuestro análisis de copilotos y programación asistida; sobre el control de credenciales de máquina, la guía de identidades no humanas.

La consulta SQL y las recomendaciones de configuración de este artículo tienen carácter orientativo y se basan en la documentación pública de Supabase y PostgreSQL y en investigaciones de terceros disponibles a 30 de septiembre de 2026. Antes de aplicarlas, valide su efecto en un entorno de pruebas y con el modelo de acceso previsto de cada aplicación. Las cifras de exposición proceden de los estudios citados y no han sido verificadas de forma independiente por Hard2bit.