Lovable: un estudio detecta datos personales accesibles sin autenticación en miles de aplicaciones
La empresa de seguridad alemana Crissy Field analizó 159 041 proyectos creados con Lovable. De los 24 664 sitios que devolvían datos de Supabase desde la carga, 7 403 permitían leer tablas que contenían direcciones de correo electrónico y, en algunos casos, números de pasaporte o datos de pago.
La promesa del «vibe coding» choca con una cuestión muy concreta: ¿quién protege los datos? La empresa de seguridad alemana Crissy Field examinó 159 041 proyectos creados con Lovable, la plataforma sueca que transforma una descripción en lenguaje natural en una aplicación web. El resultado: en miles de sitios, informaciones personales, a veces muy sensibles, eran legibles sin necesidad de iniciar sesión. La investigación, realizada junto con el diario económico alemán Handelsblatt (artículo del 2 de noviembre de 2026), se detalla en un informe publicado por Crissy Field con cifras actualizadas.
Lo que midió el estudio
Crissy Field se centró en Supabase, el servicio de bases de datos que considera el más utilizado en los proyectos de Lovable. Las bases de datos propias de Lovable, lanzadas a finales de 2025, no fueron examinadas.
| Fase | Cantidad |
|---|---|
| Proyectos de Lovable identificados en Common Crawl (dic. de 2025 a sept. de 2026) | 159 041 |
| Proyectos que utilizan Supabase | 34 545 |
| Sitios que envían registros de Supabase desde la carga, sin iniciar sesión | 24 664 |
| Sitios donde las tablas con direcciones de correo electrónico eran legibles | 7 403 (30%), sobre 10 560 tablas |
La primera cifra no representa en sí misma una vulnerabilidad: una aplicación puede mostrar públicamente ciertos datos. El problema surge en el paso siguiente. Con simples consultas de solo lectura, empleando la misma clave de API que utiliza el sitio web, los investigadores pudieron leer otras tablas. Crissy Field no publica su método de acceso para no facilitar nuevas intrusiones, y solo descargó fragmentos de las bases de datos.
De pasaportes a mensajes privados
Los ejemplos citados en el informe son de gravedad:
- un foro alemán exponía más de 80 000 perfiles (nombre, correo electrónico, fecha de nacimiento) y más de 200 000 mensajes de debate;
- organizadores de eventos y restaurantes dejaban expuestos a lectura decenas de miles de registros de ventas, con teléfonos, direcciones postales, información de pago y códigos de entradas;
- un gestor inmobiliario exponía resúmenes, generados por IA, de correos electrónicos internos sobre sus inquilinos y socios;
- un proveedor exponía más de 1 000 registros con números de pasaporte, fechas de caducidad y nacionalidades;
- en otros casos: contratos, facturas, álbumes de fotos, conversaciones internas de WhatsApp y 280 000 correos electrónicos enviados a los clientes de un suministrador.
Crissy Field afirma no saber si estos datos llegaron a ser explotados, pero recuerda que pueden utilizarse para ataques de suplantación de identidad (phishing), fraude con entradas o usurpación de identidad.
Las limitaciones de la cifra del 30%
El informe se muestra cauto respecto a su propia estadística. Una dirección de correo electrónico puede ser un contacto público o un dato de prueba; a la inversa, los registros personales que no incluyen correo electrónico escapan al recuento. Ese 30% se refiere únicamente a los 24 664 sitios examinados al detalle, y la muestra tomada de Common Crawl no es representativa del conjunto de aplicaciones de Lovable. Por lo tanto, no se trata de una tasa de filtración confirmada.
¿Quién es el responsable?
Crissy Field señala una contradicción: Lovable destaca que no se requieren competencias técnicas, mientras que sus condiciones de uso delegan en los clientes la responsabilidad sobre sus aplicaciones y sus datos. Según India Today, citando a Handelsblatt, Lovable respondió que el problema no era exclusivo de su plataforma y afectaba a todo el sector. No hemos encontrado ninguna declaración pública de la empresa hasta el momento.
Los investigadores reconocen que los errores de permisos de acceso también existen en aplicaciones programadas manualmente. Sin embargo, con Lovable, las integraciones de bases de datos siguen patrones recurrentes: una vía que funciona contra una aplicación puede repetirse contra muchas otras. Y los usuarios sin formación técnica tienen más dificultades para detectar estos fallos. Su recomendación: encargar la revisión de los permisos de acceso, las interfaces y la separación entre cuentas antes de gestionar datos reales de clientes, y repetir la comprobación tras cada cambio relevante.
Nuestro análisis
El problema no radica en la IA: una base mal configurada sigue estando mal configurada, tanto si la conectó un humano como si lo hizo un agente. Sin embargo, las herramientas de generación de aplicaciones multiplican el volumen de proyectos publicados por personas que desconocen que una base de datos sin reglas de acceso bien definidas puede leerse mucho más allá de lo que la interfaz muestra. El estudio no demuestra una filtración masiva ni una explotación efectiva, y su muestra no es representativa; en cambio, evidencia que «sin código» no equivale a «sin seguridad». Para estas plataformas, el desafío consiste ahora en hacer que la configuración sea segura por defecto y en bloquear la publicación cuando queden datos sensibles al descubierto, en lugar de trasladar la responsabilidad a los clientes. Si has publicado una aplicación de este tipo, pruébala sin iniciar sesión y haz revisar sus reglas de acceso antes de almacenar en ella datos reales.
Fuentes
- Crissy Field — Lovable: Many Apps Built on the Platform Expose Sensitive Data (informe de investigación) Fuente primaria
- India Today — AI app-maker Lovable apps expose personal details, researchers find thousands of cases (3 de noviembre de 2026) Fuente secundaria
Una fuente primaria procede directamente de la empresa, el laboratorio o la organización implicados. Una fuente secundaria recoge la información sin ser su autora: la señalamos como tal. ¿Has visto un error? Consulta nuestra política de correcciones.
