Lovable analiza cada aplicación antes de publicarla y corrige fallos de acceso en un par de clics

Has creado una aplicación en una tarde conversando con una IA, ya la usan personas reales y la pregunta «¿pero esto es seguro?» empieza a resultar incómoda. Lovable ha respondido con una publicación de su equipo de seguridad: qué hace la plataforma por su cuenta, qué problemas señala y qué deja en tus manos. Veamos qué resulta realmente útil.

Qué funciona sin tu intervención

La protección básica está activada por defecto. La autenticación y el control de acceso vienen configurados, los secretos se cifran y no se incluyen en el código del frontend, y la aplicación se analiza durante su creación. Todo esto se aplica por igual a todos los usuarios, incluidas las cuentas gratuitas. En el vibe coding es un detalle importante: alguien sin formación técnica no detectará que una clave secreta ha acabado en el código del cliente.

El ciclo «detectar, corregir y publicar»

Cada vez que publicas, los analizadores revisan el código, la lógica de la aplicación, los esquemas de la base de datos y las políticas de seguridad a nivel de fila, o row-level security (RLS). Son las reglas que determinan quién puede leer y modificar filas concretas de las tablas.

Un ejemplo sencillo. Tienes una tabla de pedidos y su política permite que cualquier usuario que haya iniciado sesión lea toda la tabla, en lugar de acceder solo a sus propios pedidos. La aplicación funciona perfectamente, nada falla y el agujero no se ve a simple vista. Según Lovable, las reglas de acceso demasiado permisivas son el problema más habitual en las aplicaciones de su plataforma. El analizador lo señalará antes del lanzamiento; tú pulsarás Fix y el agente recibirá instrucciones específicas para ese problema y reescribirá la política.

También hay otros controles:

• puedes ejecutar un análisis profundo en cualquier momento y gratis: tarda más, pero examina más a fondo. Se basa en un sistema de pruebas propio, entrenado con problemas habituales de las aplicaciones de Lovable;
• la opción «Auto-fix security issues», en los ajustes del proyecto, resuelve automáticamente muchos de los problemas detectados con tu siguiente mensaje en el chat;
• control de publicación: tú o el administrador del espacio de trabajo podéis bloquear el lanzamiento mientras haya problemas críticos pendientes.

Este último punto es, quizá, el más práctico. Convierte la seguridad en un requisito para publicar, como una comprobación de CI que falla antes del despliegue.

Qué sigue dependiendo de ti

La plataforma lo dice claramente: revisar los problemas detectados y actuar es tarea tuya, salvo que se la delegues a la corrección automática. A veces el analizador señala algo que se ha hecho de forma intencionada, como mostrar públicamente los nombres de usuario de un foro. Ahí hace falta tu criterio: la aplicación es tuya y tú tienes también la última palabra sobre lo que llega a producción.

Qué no cuenta la publicación

Es una publicación del proveedor y no incluye cifras. No ofrece datos sobre la precisión del analizador, la tasa de falsos positivos ni cuántos problemas resuelve correctamente la corrección automática. La expresión «muchos de los problemas detectados» significa que no son todos. Además, la corrección automática la realiza un agente que modifica código y políticas. Después conviene, como mínimo, revisar el diff, sobre todo si la aplicación gestiona pagos o datos personales. En mi opinión, para un producto serio, un análisis automático no sustituye a una auditoría independiente.

Entre los planes para este mes figuran una interfaz de seguridad rediseñada, con resultados más claros, y análisis periódicos programados en todos los planes de pago, sin clics adicionales.

Qué hacer con todo esto

Si estás creando un producto con Lovable:

1. Activa el bloqueo de publicación cuando haya problemas críticos y, si trabajas en un proyecto de equipo, pide al administrador que haga lo mismo.
2. Activa la corrección automática, pero revisa los cambios allí donde se almacenen datos de otras personas.
3. Ejecuta manualmente un análisis profundo antes del primer lanzamiento público.
4. Revisa los problemas «intencionados»: si los datos son públicos de forma deliberada, deja constancia de esa decisión.

Si trabajas con otra herramienta de vibe coding, la pregunta es la misma: ¿revisa las políticas RLS y los secretos antes del lanzamiento y puede bloquear la publicación? Si no, tendrás que repasar esta lista de comprobación manualmente.