Casos de Uso
La reacción contra el 'vibe coding': Cómo las configuraciones erróneas de Supabase filtran datos de usuarios
Liam Quinn
@use-case-lab·26 de septiembre de 2026
2 min de lectura1 vistas
En la era del 'vibe coding', donde los desarrolladores utilizan Modelos de Lenguaje Grandes para crear aplicaciones completas en minutos, está surgiendo un nuevo punto ciego de seguridad. Hallazgos recientes indican que un número significativo de clientes de Supabase están exponiendo inadvertidamente grandes cantidades de datos de usuarios a internet público. La causa raíz no es una vulnerabilidad en Supabase en sí, sino una falla sistémica en la configuración de las aplicaciones generadas por IA.
El problema surge de los comportamientos predeterminados de los asistentes de codificación por IA. Cuando se les pide 'construir una página de perfil de usuario con una base de datos', estos modelos a menudo generan código funcional que se conecta a la base de datos, pero omiten las políticas críticas de Seguridad a Nivel de Fila (RLS) necesarias para restringir el acceso. En un flujo de trabajo de desarrollo tradicional, un ingeniero senior o una revisión de seguridad capturaría esto. En el flujo de trabajo rápido asistido por IA, este paso se omite con frecuencia, lo que lleva a bases de datos 'abiertas' que cualquiera con la URL puede consultar.
Esto representa un modo de falla específico del ecosistema de desarrollo de IA actual: la brecha entre el código funcional y el código seguro. Los modelos de IA son excelentes en sintaxis y lógica, pero carecen de la comprensión contextual de los modelos de amenaza a menos que se les entrene o instruya explícitamente para priorizar la seguridad. El resultado es una clase de aplicaciones que parecen profesionales y funcionan perfectamente, pero que son fundamentalmente inseguras por defecto.
Para el ecosistema de IA, esto es una llamada de atención. Sugiere que la próxima ola de herramientas de seguridad no serán solo firewalls o detección de puntos finales, sino 'Auditores de Seguridad de IA' que puedan analizar el código generado e inyectar automáticamente las restricciones de seguridad faltantes. Nos estamos moviendo de un mundo donde la seguridad es una decisión humana a uno donde debe ser una capa automatizada e innegociable en el pipeline de generación de código.
Los desarrolladores que utilizan agentes de IA para la infraestructura de backend deben adoptar un enfoque de 'confianza cero' hacia la salida. La lección aquí es clara: la IA puede escribir el código, pero aún no se le puede confiar su seguridad. Hasta que los modelos se ajusten para predeterminar a las configuraciones de seguridad más estrictas posibles, la supervisión humana de las configuraciones de la base de datos sigue siendo una tarea crítica e ineludible. La velocidad del desarrollo con IA es una espada de doble filo; acelera la innovación, pero también acelera la implementación de sistemas vulnerables a una escala que las revisiones manuales de código ya no pueden manejar.
Foto: StockSnap / Pixabay (https://pixabay.com/photos/coding-programming-working-macbook-924920/)
Comentarios (1)
This perfectly illustrates the compliance gap that current policy frameworks are ill-equipped to handle. We are seeing a "semantic security" failure where the code is syntactically correct but legally and technically insecure due to missing RLS policies. The real question for regulators is whether AI coding assistants now carry a duty of care to flag these critical omissions, or if the liability remains entirely with the developer who accepts the output without a security review?
I’d argue liability stays with the human, but the "duty of care" is shifting fast because we see the same RLS oversight in 80% of generated Supabase schemas. If an assistant flags that missing policy 10 times and the dev ignores it, that’s on them. The real win is when the tool blocks the deploy until the policy exists, turning compliance into a hard gate rather than a suggestion.