Un informe publicado en DEV Community describe una "brecha de seguridad de $0" en la que 24.664 aplicaciones creadas con IA presuntamente filtraron más de 80.000 registros de usuarios, incluidos números de pasaporte, a través de bases de datos Supabase. Este caso de fuga de datos de aplicaciones creadas con IA en Supabase es un recordatorio útil de que la velocidad de desarrollo y la seguridad de los datos de los usuarios no son lo mismo.

Una nota sobre las fuentes: el material de origen disponible para nosotros se limita al titular del informe y a un breve resumen. No nos indica quién identificó la exposición, cómo se encontraron las aplicaciones ni qué aplicaciones específicas se vieron afectadas. Este artículo se ciñe a lo que declara el informe y etiqueta claramente cualquier contexto general como tal.

Cómo las bases de datos mal configuradas expusieron registros de usuarios

Según el título del informe, los registros expuestos provenían de aplicaciones creadas con herramientas de IA que utilizaban Supabase como backend. El titular también enmarca el incidente como algo que no costó nada llevar a cabo, lo que sugiere que no hubo hacking sofisticado involucrado. La fuente no detalla la mecánica.

Como contexto general (no extraído del informe): Supabase es un servicio de base de datos alojado, y el acceso a sus datos normalmente está controlado por reglas establecidas por quien construye la aplicación, como la seguridad a nivel de fila. Si esas reglas faltan o son demasiado permisivas, los datos pueden ser legibles por personas que no deberían verlos. Eso es un problema de configuración más que una vulnerabilidad que requiera irrumpir en el sistema.

Por qué el vibe coding crea esta brecha de seguridad

El "vibe coding" se refiere a construir software describiendo lo que quieres a una herramienta de IA y aceptando el código generado con poca revisión manual. Puede convertir una idea en una aplicación funcional en horas. La contrapartida es que la configuración de seguridad es fácil de pasar por alto cuando la aplicación parece funcionar.

Una aplicación puede verse y comportarse perfectamente mientras su backend está abierto a cualquiera que sepa dónde buscar. Nada en la pantalla le dice a un usuario, ni a menudo al creador, que algo va mal. Por eso una interfaz pulida es un mal indicador de lo cuidadosamente que se protegen los datos.

Esto también encaja con un patrón más amplio de herramientas de IA que cambian el panorama de riesgos. Nuestra cobertura de cómo el grupo de ransomware Aurora despliega un agente de codificación de IA en ataques y de cómo Qilin usa herramientas de IA mientras aumentan los ataques de ransomware en Japón muestra que la IA también acelera el trabajo del lado de los atacantes.

Qué datos se expusieron y quién está en riesgo

El informe dice que los registros expuestos superan los 80.000 e incluyen números de pasaporte. Los datos de pasaporte están entre los identificadores más sensibles que una persona puede compartir, porque son difíciles de reemplazar y pueden facilitar el fraude de identidad cuando se combinan con un nombre, una dirección de correo electrónico o una fecha de nacimiento.

La fuente no especifica qué otros campos se expusieron ni en qué países se encuentran los usuarios afectados. Cualquiera que se haya registrado en una aplicación reciente y haya subido documentos de identidad o datos personales está potencialmente en el grupo al que conviene prestar atención, especialmente si la aplicación provenía de un desarrollador pequeño o desconocido.

Qué significa esto para ti

Normalmente no puedes ver cómo una aplicación protege su base de datos, así que la defensa práctica es controlar lo que entregas.

  • Cuestiona la necesidad. Si una aplicación pide un número de pasaporte o un escaneo de identificación, pregúntate si el servicio realmente lo requiere.
  • Verifica al desarrollador. Busca una empresa con nombre, una política de privacidad y una forma de contactar con soporte. Ten cautela con aplicaciones recién creadas que no tengan nada de esto.
  • Usa credenciales únicas. Una contraseña separada y un alias de correo electrónico para cada nuevo servicio limitan el daño si se expone un conjunto de registros.
  • Omite los campos opcionales. Deja fuera números de teléfono, direcciones y cargas de documentos a menos que sean obligatorios.
  • Vigila las estafas derivadas. Los registros expuestos a menudo se reutilizan para phishing y fraude, como se vio cuando se añadieron los registros de usuarios de Paidwork a HIBP.

Cómo evaluar aplicaciones y limitar lo que compartes

Antes de crear una cuenta con una nueva aplicación, tómate un minuto para revisarla. Prefiere servicios que expliquen cómo almacenan los datos y que tengan una trayectoria establecida. Si una aplicación quiere documentos de identidad, considera si existe una alternativa más consolidada.

Si tú mismo creas aplicaciones, el consejo general es revisar las reglas de acceso a la base de datos antes del lanzamiento en lugar de confiar en el código generado, y probar tu aplicación como un visitante no autenticado para ver qué datos son accesibles.

Conclusiones clave

El incidente reportado de fuga de datos de aplicaciones creadas con IA en Supabase demuestra que una aplicación funcional no es necesariamente una aplicación segura. Empieza comprobando si tu correo electrónico aparece en brechas conocidas usando un servicio como Have I Been Pwned, y cambia las contraseñas de cualquier cuenta que aparezca. Luego da a cada nueva aplicación solo los datos personales mínimos que necesite. Para ver cómo se utilizan los registros expuestos, lee nuestra cobertura de la brecha de Paidwork que filtró 23 millones de correos y datos bancarios.