La exposición de datos de Supabase pone bajo presión las afirmaciones de seguridad de las apps creadas con vibe coding
Supabase enfrenta un mayor escrutinio después de que investigadores identificaran 16.326 bases de datos con tablas legibles públicamente, pese a que la plataforma describe sus proyectos como seguros por defecto. Los hallazgos sobre la exposición de datos de Supabase conectan un problema conocido de seguridad en la nube con una fuente de riesgo más reciente: aplicaciones ensambladas rápidamente mediante herramientas de programación con IA.
UpGuard encontró indicios de información personal en más de la mitad de las bases de datos expuestas. Los registros afectados incluían, según los reportes, nombres, direcciones, números de teléfono, fechas de nacimiento, contraseñas, tokens de autenticación, mensajes privados, matrículas de vehículos e información migratoria.
No se trató de una brecha en los sistemas internos de Supabase. La evidencia apunta, en cambio, a bases de datos de clientes expuestas por controles de acceso ausentes o inadecuados. Esa distinción importa, pero no hace que la escala resulte menos preocupante.
El informe convierte un fallo técnico de configuración en una prueba para el modelo de vibe coding. Los asistentes de IA pueden generar una interfaz funcional y conectarla a una base de datos alojada en cuestión de minutos. No garantizan de forma fiable que cada usuario, tabla, rol y operación reciba la política de autorización correcta.
Lo que encontró la investigación sobre la exposición de datos de Supabase
El hallazgo central de UpGuard no es una única app excepcionalmente descuidada, sino miles de proyectos construidos de forma independiente que repiten errores de seguridad similares.
Para su investigación de septiembre de 2026, UpGuard recopiló cerca de 300.000 dominios únicos que mostraban señales de uso de Supabase. Los investigadores utilizaron datos de BuiltWith y del Chrome User Experience Report para identificar sitios relevantes.
Después comprobaron si cada proyecto exponía una tabla llamada users. Este nombre común de tabla proporcionó a los investigadores un punto de partida coherente sin requerir conocimiento previo del diseño de la base de datos de cada aplicación.
La prueba generó varias respuestas posibles. Una base de datos segura o inactiva no devolvía datos accesibles. Algunas bases de datos revelaban otra tabla accesible mediante una pista en un error. Otras devolvían una página de registros.
En ese conjunto de candidatos, UpGuard identificó 16.326 bases de datos con tablas legibles. Más de la mitad contenía campos de esquema que sugerían alguna forma de información de identificación personal, según la investigación sobre la exposición de la firma.
Los investigadores analizaron principalmente los esquemas de las tablas en lugar de descargar todos los registros disponibles. Un esquema revela nombres de columnas y tipos de datos, lo que puede indicar si una tabla contiene direcciones de correo electrónico, contraseñas, números de teléfono o información de pago.
Este enfoque redujo el acceso innecesario a registros personales. También significa que la cifra de 16.326 no establece que cada base de datos contuviera información sensible ni que atacantes hubieran copiado previamente los datos disponibles.
UpGuard investigó casos seleccionados en los que los metadatos sugerían una exposición significativa. Los ejemplos muestran cómo un error de configuración puede pasar de ser deuda técnica a causar daño personal directo.
Un servicio indio de streaming para adultos expuso una tabla con información de 65.467 personas. Los campos incluían, según los reportes, documentos de identidad, direcciones, fechas de nacimiento, cuentas financieras y números parciales de identificación gubernamental. Otra tabla contenía más de 100.000 mensajes privados que involucraban a creadores de contenido.
Una operación de SIM virtual en Filipinas expuso información de más de 2.000 usuarios y más de 100.000 mensajes de texto. La mayoría de los mensajes contenía códigos de un solo uso, pero la muestra también incluía miles de comunicaciones ordinarias entre conductores y pasajeros de servicios de transporte.
Un servicio de aparcacoches de Estados Unidos expuso registros de más de 100.000 clientes. Su base de datos incluía aproximadamente 78.000 números de matrícula, cerca de 43.000 direcciones de correo electrónico, historiales de visitas, información sobre propinas y notas de texto libre.
Los investigadores también hallaron una base de datos de un consulado gubernamental africano que contenía 25.000 registros. Algunas entradas identificaban las ubicaciones de alojamiento de emergencia de personas pertenecientes a una población potencialmente vulnerable.
Un servicio de inmigración canadiense expuso casi 5.000 registros. UpGuard afirmó que 884 incluían contraseñas almacenadas en texto sin formato, lo que significa que la aplicación había fallado tanto en el control de acceso como en el manejo de contraseñas.
Estos casos respaldan la conclusión más amplia y, al mismo tiempo, revelan distintas capas de fallo. El acceso público a las tablas abrió la puerta, pero un diseño deficiente de la aplicación hizo que el contenido fuera más peligroso.
La cobertura original indicó que la mayoría de los conjuntos de datos afectados parecían estar vinculados con Estados Unidos. No obstante, UpGuard encontró proyectos expuestos en todo el mundo y describió el problema como global.
La dispersión geográfica importa porque Supabase sirve como infraestructura común para pequeñas aplicaciones, nuevos negocios y organizaciones consolidadas. Por lo tanto, un patrón de configuración repetido puede afectar a usuarios no relacionados en varios sectores y jurisdicciones legales.
Por qué la base de datos era accesible desde la web
La clave pública dentro de una aplicación de Supabase no es necesariamente la vulnerabilidad. El control decisivo es qué se le permite hacer a esa clave.
Supabase proporciona una base de datos PostgreSQL alojada junto con autenticación, almacenamiento e interfaces de datos generadas automáticamente. Una aplicación web puede realizar solicitudes mediante su Data API utilizando una clave publicable.
A veces los desarrolladores asumen que encontrar esta clave en el código del navegador demuestra que se ha filtrado. Supabase diseña explícitamente las claves publicables para clientes públicos, incluidos sitios web y aplicaciones móviles.
La protección real procede de los permisos y de Row Level Security, normalmente abreviado como RLS. RLS es una función de PostgreSQL que aplica reglas de autorización dentro de la base de datos antes de devolver o modificar filas individuales.
Un usuario que ha iniciado sesión podría recibir permiso para leer únicamente los registros que llevan el identificador de ese usuario. Un visitante que no ha iniciado sesión podría no recibir acceso alguno. Otra política podría permitir que todos lean un catálogo de productos deliberadamente público.
La documentación de seguridad de Supabase indica que los desarrolladores deben habilitar RLS para las tablas expuestas y configurar políticas de acuerdo con el principio de mínimo privilegio. La clave publicable se considera segura solo cuando esos controles restringen correctamente el acceso.
La plataforma también proporciona claves secretas o de rol de servicio para sistemas backend de confianza. Esas claves omiten RLS y nunca deben aparecer en un navegador, una aplicación distribuida o un repositorio público.
Esta arquitectura crea un límite de seguridad sutil. Es esperable que una clave publicable sea visible, pero también ofrece a un visitante no autenticado una ruta hacia todo aquello a lo que la base de datos permite acceder al rol anon.
Si una tabla carece de RLS, tiene permisos excesivos o utiliza una política que permite todas las filas, una persona externa puede consultarla mediante la misma interfaz que utiliza la aplicación legítima. No se requiere ninguna intrusión sofisticada.
Los investigadores de UpGuard encontraron proyectos objetivo examinando JavaScript entregado públicamente en busca de identificadores de Supabase. Después podían preguntar a cada base de datos si una tabla común estaba disponible mediante su interfaz pública.
Esa técnica se parece al comportamiento habitual de una aplicación. La diferencia radica en quién envía la solicitud y en si la base de datos puede distinguir a un usuario autorizado de cualquier otra persona en internet.
La guía detallada sobre RLS de Supabase advierte que una tabla en un esquema expuesto puede ser legible o modificable cuando RLS está ausente y el rol solicitante tiene permisos adecuados. Recomienda probar tanto las operaciones permitidas como las denegadas para roles anónimos y autenticados.
Por eso, rotar únicamente una clave publicable no resuelve el problema subyacente. La nueva clave sigue siendo recuperable desde el cliente, mientras que la política defectuosa de la base de datos continúa otorgando acceso.
Los desarrolladores deben, en cambio, revisar los esquemas expuestos, los permisos de las tablas, el estado de RLS, las condiciones de las políticas, las vistas de la base de datos y las credenciales del servidor. También necesitan pruebas que confirmen que los usuarios no pueden leer ni modificar los registros de otro usuario.
Las vistas merecen especial atención. Por defecto, las vistas de PostgreSQL pueden evaluar permisos a través de su propietario, lo que potencialmente evita las restricciones que protegen las tablas subyacentes. Por tanto, un proyecto puede habilitar RLS en todas partes y aun así divulgar datos mediante una vista insegura.
La misma distinción se aplica a la autenticación. Exigir que alguien inicie sesión no mantiene automáticamente separados a los inquilinos. Cada usuario autenticado puede seguir obteniendo un acceso amplio si la política solo comprueba que existe una sesión válida.
La seguridad de Supabase explicada a nivel de clave es, por tanto, sencilla. Los clientes públicos necesitan un identificador público, mientras que las políticas de la base de datos imponen el límite real. La dificultad consiste en traducir las reglas previstas de una aplicación en políticas completas y probadas.
El vibe coding convierte una brecha de configuración en un patrón repetido
Los riesgos de seguridad del vibe coding aumentan cuando un asistente de IA optimiza para un resultado visible mientras la autorización permanece oculta para la persona que lo dirige.
Un equipo de desarrollo convencional también puede configurar incorrectamente una base de datos. Los buckets públicos de Amazon S3, los clústeres de Elasticsearch expuestos y las credenciales de nube filtradas existían mucho antes de que la IA generativa entrara en el desarrollo de software.
Lo que cambia con el vibe coding es la combinación de velocidad, accesibilidad y revisión limitada. Una persona puede solicitar una app en lenguaje natural, aceptar código generado, conectar un backend alojado y desplegarla sin comprender los límites de confianza.
La aplicación puede parecer completa porque el registro funciona, los registros se guardan correctamente y las páginas cargan. Esas pruebas confirman la funcionalidad. No confirman que una cuenta no pueda consultar los registros de otra cuenta.
Los fallos de autorización son especialmente fáciles de pasar por alto durante una demostración del flujo ideal. El desarrollador ve el perfil esperado después de iniciar sesión y supone que el sistema lo ha protegido. Un atacante formula una pregunta distinta: ¿qué ocurre cuando la solicitud omite una sesión o cambia un identificador de registro?
Los agentes de programación con IA también interactúan con la infraestructura de forma programática. UpGuard señaló que Supabase habilita RLS por defecto para las tablas creadas mediante partes de su panel, mientras que las tablas creadas programáticamente requieren atención adicional.
Esa diferencia puede adquirir relevancia cuando un agente crea un esquema de base de datos mediante SQL o una API. Un ajuste protector vinculado a un flujo de creación no cubre automáticamente todas las rutas de acceso a la plataforma.
Supabase reconoció este desafío más amplio de usabilidad en su revisión de seguridad de 2025. La empresa afirmó que RLS es flexible, pero puede ser complejo para desarrolladores que no conocen el patrón.
Durante 2025, Supabase añadió valores predeterminados más seguros y amplió su Security Advisor. También otorgó a los proyectos mayor control sobre la Data API, incluida la opción de desactivarla o exponer un esquema personalizado en lugar del esquema predeterminado public.
Estos cambios ayudan, pero no eliminan los proyectos existentes ni corrigen todas las migraciones generadas. Las herramientas de seguridad pueden señalar errores comunes, aunque una política puede seguir siendo lógicamente incorrecta mientras supera una comprobación básica.
Una regla generada podría comparar el identificador equivocado, pasar por alto una ruta de actualización o proteger las lecturas mientras permite escrituras no autorizadas. Podría funcionar para una tabla, pero dejar pública una tabla relacionada.
El supervisor humano del agente debe reconocer que existe el comportamiento ausente. Un principiante que no conoce RLS, las concesiones de roles o el aislamiento de inquilinos quizá nunca le pida al modelo que los pruebe.
Esto crea una asimetría entre construir y auditar. Generar una función requiere una sola instrucción. Demostrar que esa función gestiona de forma segura cada identidad y operación exige un modelo de amenazas, pruebas negativas y un examen cuidadoso de los artefactos generados.
Estudios anteriores sugieren que se trata de un patrón recurrente y no de un resultado aislado de una encuesta. UpGuard citó investigaciones en las que participaron empresas de Y Combinator, aplicaciones creadas mediante plataformas de desarrollo con IA y sitios independientes.
Modern Pentest informó que el 28 por ciento de 107 startups de Y Combinator examinadas expusieron información personal a través de configuraciones de Supabase. Otro estudio revisó 1.072 aplicaciones programadas por vibras y encontró 39 con tablas legibles mediante una clave pública de Supabase.
Las muestras y los métodos difieren, por lo que sus porcentajes no deben combinarse. Sin embargo, cada investigación encontró versiones del mismo fallo: información de conexión visible para el cliente junto con permisos de base de datos más amplios de lo que pretendía la aplicación.
Un incidente de febrero de 2026 hizo que las consecuencias fueran particularmente visibles. La empresa de seguridad Wiz descubrió que Moltbook, una red social presentada como plataforma para agentes de IA, tenía un backend de Supabase mal configurado.
Según la investigación sobre Moltbook, la base de datos permitía acceso de lectura y escritura a los datos de la plataforma. El material expuesto incluía 35.000 direcciones de correo electrónico y 1,5 millones de tokens de autenticación de API.
Wiz afirmó que detectó el problema al revisar JavaScript del lado del cliente durante una evaluación no intrusiva. El equipo de Moltbook protegió la base de datos en cuestión de horas tras la divulgación.
El episodio ofreció un ejemplo conciso de la disyuntiva actual. La asistencia de IA ayudó a crear rápidamente un servicio que atrajo atención, pero el éxito visible de la aplicación ocultaba un fallo crítico en los controles de la base de datos.
Para las organizaciones que evalúan software creado con IA, esto cambia el significado de un prototipo funcional. Una demostración ahora prueba menos sobre la preparación para producción, porque la IA puede completar flujos de trabajo visibles antes de que alguien valide el modelo de seguridad subyacente.
Una base de conocimiento de ingeniería interna puede ayudar a los equipos a conservar las decisiones de arquitectura y la evidencia de revisión. No puede sustituir las pruebas de base de datos, pero puede evitar que las suposiciones de seguridad desaparezcan entre instrucciones y transferencias.
“Seguro por defecto” frente a responsabilidad compartida
El conflicto principal surge entre los valores predeterminados seguros de la plataforma y un modelo de responsabilidad compartida que todavía deja a clientes sin experiencia controlando configuraciones importantes.
El director de seguridad de la información de Supabase, Bil Harmer, declaró a TechCrunch que la empresa no había revisado la investigación de UpGuard antes de hacer comentarios. Afirmó que los proyectos de Supabase son seguros por defecto y describió la seguridad como una responsabilidad compartida.
Esa postura refleja un modelo estándar de nube. El proveedor protege su plataforma alojada y ofrece controles de acceso. Los clientes deciden qué usuarios y aplicaciones deben acceder a sus datos.
La distinción es válida. UpGuard no informó haber vulnerado los sistemas corporativos de Supabase ni eludido una política de RLS correctamente configurada. Las bases de datos expuestas pertenecían a clientes cuyos ajustes permitían un acceso más amplio.
Sin embargo, los valores predeterminados no pueden evaluarse solo al crear un proyecto. También incluyen las rutas prácticas que las personas y los agentes de programación utilizan para crear tablas, publicar API, copiar ejemplos y desplegar aplicaciones.
Un sistema puede empezar de forma segura y quedar expuesto más tarde mediante una migración generada por un agente. También puede ofrecer un flujo de trabajo seguro en el panel mientras que un flujo programático crea un estado de seguridad diferente.
Por tanto, la expresión “seguro por defecto” necesita un límite definido. ¿Significa que un proyecto nuevo no expone nada? ¿Abarca todas las rutas compatibles para crear tablas? ¿Alerta a los usuarios antes de que datos de producción entren en una tabla sin RLS?
La responsabilidad compartida también presupone que cada parte comprende su cometido. Los ingenieros de nube con experiencia saben que un identificador público de cliente debe combinarse con autorización del lado del servidor. Muchos programadores por vibras no lo saben.
Esa brecha de conocimientos no hace que la plataforma sea la única responsable de los errores de los clientes. Pero sí aumenta la presión sobre Supabase y los proveedores de programación con IA para hacer que los estados inseguros sean más difíciles de crear y más fáciles de detectar.
La plataforma ya ha avanzado en esa dirección. Security Advisor de Supabase comprueba problemas comunes de bases de datos, mientras que su lista de verificación para producción indica a los usuarios que activen RLS en todas las tablas pertinentes y revisen las políticas.
Un diseño más estricto podría bloquear el acceso de producción a una tabla sin protección o exigir una anulación explícita. Estas medidas reducirían las exposiciones accidentales, pero también podrían obstaculizar conjuntos de datos públicos legítimos y el desarrollo rápido.
Supabase debe equilibrar esos casos sin tratar cada tabla pública como una vulnerabilidad. El menú de un restaurante, una clasificación pública o un directorio publicado pueden permitir razonablemente lecturas anónimas.
La plataforma no puede inferir la intención únicamente a partir del nombre de una tabla. Una tabla users es más sospechosa que una tabla products, pero una aplicación podría publicar intencionadamente perfiles de usuario mientras mantiene privadas las direcciones de correo electrónico.
Las herramientas automatizadas afrontan la misma ambigüedad. Pueden detectar que un rol anónimo puede leer una tabla. Determinar si el acceso vulnera la promesa del producto requiere contexto empresarial.
Esa es la disyuntiva central. Las políticas flexibles de bases de datos permiten a los desarrolladores crear muchos tipos de aplicaciones, pero la flexibilidad deja margen para errores silenciosos. Las restricciones rígidas evitan errores, a la vez que limitan diseños legítimos.
Los asistentes de IA añaden otra parte responsable. Un desarrollador puede elegir Supabase porque un agente se lo recomendó y luego confiar en ese agente para generar el esquema y las políticas.
El proveedor del modelo no aloja la base de datos, mientras que Supabase no controla cada comando generado. El propietario de la aplicación sigue siendo responsable ante los usuarios, incluso cuando no puede explicar el modelo de autorización resultante.
Esta cadena fragmentada hace que los fallos de seguridad sean más difíciles de atribuir y más fáciles de repetir. Cada participante puede señalar la documentación o la configuración de otra parte, mientras que la persona afectada solo ve que su información privada se hizo pública.
Para los compradores empresariales, la respuesta práctica es evaluar el sistema de desarrollo completo. Las certificaciones de los proveedores importan, pero también los controles de despliegue, la revisión de código, las pruebas de bases de datos, los registros, la respuesta a incidentes y la experiencia de las personas que supervisan a los agentes de IA.
Lo que muestran las cifras, y lo que no
El estudio demuestra una amplia superficie de exposición, pero su metodología no establece 16.326 vulneraciones confirmadas ni mide la totalidad de la base de clientes de Supabase.
UpGuard partió de dominios que mostraban indicadores de uso de Supabase, no de una muestra aleatoria de todas las aplicaciones de la plataforma. Sus fuentes favorecían sitios visibles a través de conjuntos de datos sobre tecnologías web.
Los investigadores consultaron después una tabla llamada users. Esa elección fue sensata porque muchas aplicaciones mantienen registros de usuarios, pero también orientó la encuesta hacia bases de datos con probabilidades de contener información personal.
UpGuard reveló esta limitación. La empresa afirmó que sus resultados estaban sesgados hacia la PII en parte porque eligió deliberadamente una tabla común asociada a personas.
El total de 16.326 abarca bases de datos que exponen tablas legibles. No significa que cada tabla contuviera registros confidenciales. Algunos proyectos podrían haber publicado datos intencionadamente, utilizado información sintética o haber sido abandonados.
El análisis de esquemas también mide la posible exposición de manera distinta a una investigación forense registro por registro. Una columna llamada password es una advertencia seria, pero su mera existencia no demuestra que contuviera credenciales activas.
Los investigadores validaron manualmente casos seleccionados e informaron recuentos concretos de registros de esas bases de datos. Esos ejemplos muestran que al menos algunas exposiciones implicaban datos reales y sensibles a una escala significativa.
La investigación tampoco puede determinar cuántos terceros accedieron a las bases de datos antes de la divulgación. La disponibilidad pública crea riesgo, pero no prueba que actores criminales descubrieran o descargaran la información.
Esta diferencia separa una exposición de datos de una vulneración de datos confirmada. Una exposición significa que era posible el acceso no autorizado. Una vulneración generalmente requiere evidencia de que una parte no autorizada realmente accedió o adquirió los datos.
Las organizaciones no deberían usar esa distinción para minimizar el incidente. Una vez que los registros sensibles son accesibles sin la autorización adecuada, los investigadores pueden carecer de registros suficientes para demostrar quién accedió a ellos.
El estudio tampoco calcula una tasa de exposición entre todos los proyectos de Supabase. UpGuard analizó unos 300.000 dominios candidatos, mientras que una organización puede operar múltiples dominios o proyectos.
Los sitios inactivos y los falsos indicadores tecnológicos pueden complicar ese denominador. La cifra final se entiende mejor como una población descubierta, no como un porcentaje de los clientes de Supabase.
Incluso con esas salvedades, 16.326 bases de datos legibles representan una superficie de ataque considerable. Un actor malicioso podría automatizar el mismo proceso general de descubrimiento y priorizar las tablas que contengan campos valiosos.
Los casos detallados también debilitan el argumento de que se trataba de proyectos de demostración inofensivos. Los registros de inmigración, ubicaciones de alojamientos de emergencia, comunicaciones privadas para adultos, matrículas y códigos de un solo uso tienen claras implicaciones de privacidad y seguridad.
La respuesta de Supabase merece la misma precisión. La empresa afirmó que notifica a los clientes afectados cuando tiene conocimiento de problemas de seguridad. Eso no confirma cuántos proyectos fueron notificados, con qué rapidez respondieron ni cuántas exposiciones seguían abiertas.
UpGuard afirmó que notificó a los propietarios de aplicaciones en los casos significativos que validó. Su informe público no proporcionó una tasa de corrección completa para las 16.326 bases de datos.
Esas lagunas deberían orientar la cobertura de los hallazgos. La evidencia respalda un problema de configuración generalizado y varias exposiciones graves. No respalda afirmar que Supabase fue hackeada ni que cada base de datos identificada filtró registros sensibles.
También deja sin respuesta una importante cuestión comparativa. Bases de datos alojadas comparables podrían mostrar problemas similares si los investigadores aplicaran un método equivalente a escala de internet.
Firebase, Appwrite, los despliegues autogestionados de PostgreSQL y otros servicios backend exponen interfaces diferentes y utilizan distintos modelos de permisos. Los desarrolladores pueden configurar incorrectamente cualquiera de ellos.
Supabase atrae atención porque su arquitectura orientada al cliente, sus API automáticas y su popularidad en los flujos de trabajo de programación con IA hacen visible el problema. La popularidad aumenta tanto el número de despliegues seguros como el de errores.
Por tanto, una evaluación justa debería evitar presentar a Supabase como singularmente incapaz de proteger los datos. La conclusión más sólida es que su adopción entre creadores sin experiencia convierte la usabilidad del control de acceso en una preocupación a nivel de plataforma.
Tres señales mostrarán si el riesgo está disminuyendo
La próxima fase debería juzgarse mediante cambios de producto medibles, evidencia de corrección y nuevas pruebas independientes, en lugar de promesas generales de seguridad.
La primera señal es cómo Supabase gestiona las tablas creadas programáticamente. Los agentes de programación suelen trabajar mediante SQL, interfaces de gestión y migraciones automatizadas, en lugar de clics manuales en el panel.
Un cambio significativo haría que RLS y las concesiones restrictivas fueran coherentes en todas las rutas de creación, o exigiría una decisión explícita antes de que una tabla sea accesible a través de la Data API. Advertencias claras dentro de los flujos de trabajo de agentes reforzarían esa protección.
Si Supabase cierra la brecha entre la creación mediante el panel y la creación programática, reforzaría la idea de que unas configuraciones predeterminadas más seguras pueden reducir los riesgos de seguridad del vibe coding. Si los flujos de trabajo siguen siendo diferentes, los creadores sin experiencia continuarán entrando en estados inseguros sin reconocerlos.
La segunda señal son los datos de remediación. Supabase y UpGuard pueden aclarar cuántos proyectos identificados recibieron avisos, cuántos propietarios respondieron y cuántas bases de datos dejaron de exponer registros no intencionados.
Una alta tasa de remediación demostraría que las notificaciones y las herramientas de seguridad pueden reducir el retraso acumulado existente. Una tasa baja sugeriría que muchos proyectos están abandonados, reciben un mantenimiento deficiente o son operados por personas incapaces de corregir la configuración.
Las organizaciones afectadas también deben determinar si los registros expuestos requieren notificación a los usuarios o comunicación a los reguladores. Esa decisión depende de la ubicación, el tipo de datos, la evidencia de acceso y la legislación aplicable.
La tercera señal es la repetición de pruebas independientes durante los próximos meses. Los investigadores deberían realizar análisis comparables y publicar métodos transparentes que distingan los datos públicos intencionados de las exposiciones de información sensible.
Una disminución del número de bases de datos respaldaría la estrategia de configuraciones predeterminadas más seguras de Supabase. Una cifra estable o creciente indicaría que el crecimiento de la plataforma y el desarrollo asistido por IA están creando proyectos inseguros más rápido de lo que los controles existentes pueden corregirlos.
Los proveedores de programación con IA también merecen escrutinio durante esas nuevas pruebas. Sus agentes deberían crear políticas de mínimo privilegio, generar pruebas negativas de autorización y advertir cuando un despliegue expone información personal.
Los desarrolladores no necesitan abandonar Supabase ni la programación con IA para responder de forma responsable. Deben tratar el software generado como no confiable hasta que se haya probado su comportamiento de autorización.
Eso implica comprobar por separado el acceso anónimo y autenticado, probar cada operación de base de datos, revisar las vistas, proteger las claves de servidor y desactivar las interfaces que la aplicación no necesita.
Los equipos también deberían conservar las decisiones que respaldan esos controles. Una base de conocimientos de IA con capacidad de búsqueda puede conectar requisitos, migraciones generadas, hallazgos de auditoría y trabajo de remediación sin convertir la documentación en una ocurrencia tardía.
La historia de la exposición de datos de Supabase trata, en última instancia, de una brecha de responsabilidad. Las plataformas ofrecen controles configurables, los agentes de IA ensamblan aplicaciones y los usuarios confían en la interfaz terminada.
¿Quién verifica los permisos invisibles antes de que información real entre en el sistema? Cualquier organización que publique una aplicación generada por IA debería poder responder a esa pregunta con resultados de pruebas, responsables designados y evidencia de accesos denegados.
