Escaneo de seguridad de Lovable: lo que no puede probar

Le das a Publish en tu aplicación Lovable y, antes de que salga, corre un escaneo. Unos segundos después vuelve limpio, o vuelve con una lista, y en cualquiera de los dos casos tienes en la mano un resultado que no sabes juzgar. ¿Eso es todo? ¿Basta para poner gente real encima?

Y esta es la parte que conviene saber antes de decidir: el escaneo de seguridad de Lovable y un escaneo de tu aplicación publicada leen dos objetos distintos. Uno lee las cerraduras y el cableado. El otro se acerca y baja el picaporte. Los dos merecen la pena, y solo el segundo hace lo que hace cada visitante de tu aplicación todo el día.

¿Lovable revisa mi aplicación en busca de problemas de seguridad?

Sí, y son dos. Los dos son gratis.

El Quick scan corre solo cada vez que publicas y termina en segundos. El Deep scan lee todo el código de tu aplicación y lo lanzas tú. Los dos leen tu proyecto desde dentro: la configuración de tu base de datos, las reglas de acceso de tus tablas, tu árbol de dependencias, tu código.

Todo lo que viene está leído de la propia documentación de seguridad de Lovable el 24 de septiembre de 2026. Esta función ha cambiado más de una vez en un año, así que mira la fecha de cualquier artículo que la describa, este incluido.

Qué revisa el escaneo de seguridad de Lovable

Tres áreas, como un conjunto fijo de comprobaciones, en segundos, en cada publicación.

La documentación de Lovable las llama revisión de la base de datos, auditoría de dependencias y comprobación de servidor MCP. La revisión de la base de datos es la que importa en este artículo, y su descripción merece leerse despacio: cubre tablas sin control de acceso por registro, es decir sin Row Level Security, además de reglas de acceso que dejan pasar a todo el mundo y la protección contra contraseñas filtradas apagada. La auditoría de dependencias busca vulnerabilidades conocidas en tus paquetes de npm. La comprobación de MCP busca un servidor MCP que tu aplicación exponga sin autenticación.

Los hallazgos vuelven agrupados por área y etiquetados Critical, Warning o Info. El escaneo salta automáticamente desde el diálogo de publicación, y además puedes lanzarlo desde la vista Security del proyecto.

Algunos artículos lo llaman Basic scan. El control de la vista Security hoy pone Run quick scan, así que si un artículo y tu pantalla no se ponen de acuerdo en el nombre, tu pantalla es la actual.

Qué añade el Deep scan

Lee todo el código de tu aplicación, y no se lanza solo.

El Deep scan incluye todo lo del Quick scan y después mira tu propia lógica, tus permisos y tus datos. Lovable enumera siete áreas: control de acceso y autorización, endpoints sin autenticar y abusables, entrada insegura e inyección, secretos y credenciales filtrados, pagos y facturación, autenticación y seguridad de cuentas, y datos personales y sensibles expuestos. También es gratis.

La frase de la documentación por la que hay que actuar de verdad es esta: el Deep scan no corre automáticamente mientras trabajas. Corre cuando tú lo corres. A un proyecto donde nunca se ha lanzado uno nunca le han leído el código, por muchas veces que se haya publicado, y el diálogo de publicación no te lo dice. Los espacios de trabajo Enterprise pueden programar Deep scans sobre proyectos seleccionados desde el Workspace Security center, y esa es la única configuración en la que ocurre sin que nadie se acuerde.

Lovable también puede intentar arreglos, mientras construyes o con Try to fix all en la vista Security. Lee qué ha cambiado un arreglo antes de aceptarlo. La reparación que hace desaparecer un error de row level security es muy a menudo una política que deja pasar a todo el mundo, y esa política cumple la comprobación y deja la tabla abierta.

La crítica de 2025, y qué cambió

La primera versión de esta comprobación te decía que existía una política. No te decía si la política funcionaba, y el investigador que encontró el problema original lo escribió así en su momento.

En mayo de 2025 Matt Palmer publicó CVE-2025-48757, sobre aplicaciones Lovable cuyas tablas de Supabase tenían el row level security ausente o escrito con demasiada manga ancha. La respuesta de Lovable fue la comprobación previa a publicar. El propio texto de Palmer describía su límite en un paréntesis:

La función Publish de Lovable ayuda a asegurar que las políticas RLS están activadas en todas las tablas y avisa cuando no lo están (pero no indica necesariamente si son suficientes).

Ese hueco tiene respuesta en la documentación actual, que nombra las reglas de acceso que dejan pasar a todo el mundo como algo que la revisión de la base de datos señala. Nada en este artículo comprueba esa afirmación. Si la quieres comprobar, crea una tabla de usar y tirar con una política que deje pasar a todo el mundo y mira si el escaneo la nombra. La versión larga del CVE está en ¿es seguro Lovable?.

Lo que un escaneo desde dentro no puede probar

Si tu aplicación en vivo entrega filas a alguien que no ha iniciado sesión.

Una cerradura puede estar puesta, inventariada y correcta en el plano, y la puerta abrirse igual. Una política es una declaración de lo que debería pasar; lo que decide lo que pasa es una petición. Tres maneras de que una regla figure como presente y la tabla responda igual:

• La política deja pasar a todo el mundo. Escrita como using (true), es una política válida, cumple el requisito de que exista una, y devuelve todas las filas a cualquiera que llame.
• La política cubre la lectura y nada más. El select se comprueba, el insert, el update y el delete nunca se escribieron, así que cualquiera puede escribir en una tabla que nadie puede leer entera.
• La condición encaja con más gente de la prevista. Tenía que nombrar a un cliente y nombra a cada visitante con sesión, o a cada visitante.

Ahora la parte que decide cómo deberías leer un resultado verde. Desde fuera, esas tres y una tabla sin ninguna protección dan la misma respuesta, que son filas. Tus usuarios no las distinguen. Nadie más que abra tu aplicación tampoco.

Entre el 12 y el 14 de agosto de 2026 pasamos las mismas nueve comprobaciones externas por 30.998 aplicaciones en vivo, y 18.554 de ellas estaban publicadas en Lovable. De las aplicaciones Lovable que nombraban un proyecto de Supabase, 3.553 nos respondieron con claridad suficiente para juzgarlas, y 2.017 de esas devolvieron filas a una petición que no llevaba ninguna sesión iniciada. El método y todos los denominadores están en el informe.

Un apunte honesto sobre ese número. Nosotros estábamos en la acera, y no vemos el interior de ninguno de esos proyectos. Podemos contar qué respondieron 2.017 aplicaciones publicadas. No podemos contar cuántas de ellas habían lanzado un escaneo, ni qué les dijo.

Tu propia aplicación responde a la misma pregunta en unos 20 segundos, y no tienes que creernos sobre en qué lado de las 2.017 cae: escanear tu aplicación. El escaneo le pide a cada tabla el número de filas que recibiría alguien sin sesión iniciada, lee el número y se para ahí, sin traerse una sola fila.

Lo que un escaneo desde fuera no puede ver

Bajar el picaporte no te dice nada de una habitación sin puerta a la calle, y hay cuatro de esas.

Tu árbol de dependencias de npm no está en la página que descarga un navegador. Tu código de servidor, incluidas las edge functions y si una ruta comprueba quién llama, corre en un sitio al que nunca llegamos. Una tabla que tu frontend nunca nombra nos resulta invisible, porque encontramos nombres de tablas en el código que envía tu aplicación más una lista corta de nombres habituales, así que a una tabla que no aparece en el navegador y que nadie adivinaría no se le pregunta. Y un servidor MCP no es algo que encuentre una petición de página.

Los dos escaneos de Lovable leen entre ambos los cuatro. El nuestro escribe "No se pudo comprobar" cuando no pudo responder a una pregunta, en lugar de una marca de visto.

La fila sobre qué entrega tu aplicación publicada a un desconocido es la razón para correr los dos, y nuestro escaneo está construido alrededor de ella. La versión general de dónde se acaba la vista desde fuera está en qué se le escapa a un escaneo por URL.

Los dos, y en este orden

El escaneo de dentro antes de publicar, el de fuera después, porque ese es el orden en que pasan las dos cosas.

1. Deja que el Quick scan corra al publicar y luego léelo. Son unos segundos, y va a pasar de todas formas. Pasar el diálogo de largo es la manera más común de que un hallazgo Critical llegue a producción.
2. Lanza un Deep scan antes de que algo real salga en vivo, y otra vez después de añadir inicio de sesión, pagos o cualquier tabla con personas dentro. Solo no va a correr.
3. Publica.
4. Escanea la dirección publicada desde fuera. El nuestro lee tu aplicación en vivo como lo haría un visitante, tarda unos 20 segundos, no necesita cuenta y nombra las comprobaciones que no pudo terminar: escanear tu aplicación.

En esa secuencia hay un hueco, y es con el que merece la pena contar. El Quick scan corre cuando publicas. La mayoría de lo que abre una tabla no pasa por publicar: cambias un ajuste en el panel de Supabase, aceptas a medianoche una política que te ha escrito un asistente en una ventana de chat, creas una tabla esta mañana y la pantalla que la lee sale el jueves. Nada de eso es una publicación, así que nada de eso lanza un escaneo, y el Deep scan no iba a correr solo de todos modos.

Reeve Monitor se encarga de la mitad de fuera los días que no te acuerdas. Pasa las nueve comprobaciones cada hora en hasta tres aplicaciones, vigila si tu aplicación responde siquiera, te avisa cuando un resultado cambia en lugar de esperar a que vayas a mirar, y manda un informe a final de mes.

Leer un resultado verde

Un resultado limpio significa que todas las preguntas que ese escaneo podía hacer volvieron limpias el día que lo lanzaste. Eso vale algo, y no es un veredicto sobre tu aplicación.

Lovable pone la misma advertencia en su propia documentación: las herramientas ayudan a identificar problemas de seguridad habituales y no pueden garantizar una seguridad completa. El nuestro la lleva también, porque una comprobación externa automática no es una auditoría y una lista de hallazgos vacía no es una garantía.

La única regla para cuando los dos no coinciden: si el escaneo de dentro sale limpio y uno de fuera dice que una tabla respondió a una petición sin sesión iniciada, actúa según la respuesta de fuera. Es la respuesta que reciben tus usuarios, y es la que recibe cualquier otro. Ve y lee la política de esa tabla.

Si tu aplicación está en Supabase, la guía en lenguaje llano para esta plataforma es ¿es segura tu aplicación Lovable?, y las comprobaciones escritas como comandos que puedes correr tú están en el verificador de seguridad de Supabase.

Qué hacer esta semana

Si tu aplicación Lovable usa Supabase, abre una ventana de navegación privada y repasa la lista de Authentication y Policies antes del viernes. ¿Puede cualquiera leer tu base de datos de Supabase? es el mismo test escrito como comandos que puedes pegar en un terminal.