¿Es seguro Lovable? Lo que vimos en 18.554 aplicaciones Lovable

Construiste algo en Lovable, funciona, y estás a punto de poner gente real encima. En algún momento de esa semana escribiste "es seguro lovable" en un buscador, y lo que volvió fue o bien una página sobre una divulgación de seguridad de 2025 o bien un proveedor vendiéndote un escaneo. Ninguna de las dos decía nada sobre la aplicación que estás a punto de publicar.

Esto es lo que la mayoría de esas respuestas se pierde: "es seguro Lovable" son tres preguntas vestidas de una sola frase, y la que decide si un desconocido puede leer los datos de tus usuarios es la que casi nadie mide.

Nosotros podemos medirla. Entre el 12 y el 14 de agosto de 2026 pasamos 30.998 aplicaciones en vivo por las mismas nueve comprobaciones externas que cualquiera puede lanzar gratis en nuestra página de inicio, y 18.554 de ellas estaban publicadas en Lovable. Es la cohorte más grande que tenemos, tres de cada cinco aplicaciones que hemos escaneado nunca. Esto es lo que volvió para ellas, y hasta dónde llega nuestra vista.

¿Es seguro Lovable?

Como plataforma, sí, y por un margen más amplio del que esperábamos. Lo que produce Lovable fue lo más limpio de los cinco constructores que medimos. Todo lo que decidió una nota estaba dentro de la aplicación que había construido su dueño.

Piensa en una tienda con el almacén al otro lado de la calle. Lovable construye la tienda: los escaparates, el mostrador, el cartel. El almacén es de Supabase, y tiene su propia cerradura en su propia puerta. Lo que la tienda le da a un transeúnte es una pregunta. Lo que el almacén le da a cualquiera que se acerque y pregunte es otra completamente distinta, y por mucho que ordenes la tienda eso no cambia.

1. La plataforma. ¿Publica Lovable tu aplicación como es debido: un certificado válido, un dominio que no caduca, nada que se escape del build? Esta es la tienda.
2. El agente. ¿Es sólido el código que escribe la IA de Lovable? Ningún escaneo externo ve el cableado, y este artículo lo dice en vez de adivinarlo.
3. La aplicación que publicaste. Lo que un desconocido alcanza desde la acera: una clave en el código que descarga un navegador, un bucket de almacenamiento que lista sus archivos, una tabla de base de datos que responde a cualquiera que pregunte.

Nuestras comprobaciones leen la tercera y dos partes de la primera. En la plataforma, el certificado era válido en las 18.486 aplicaciones donde pudimos leer uno, y ni un solo dominio de 18.554 estaba cerca de caducar. Del agente no tenemos nada que medir. De la aplicación tenemos 18.554 respuestas.

Lo que encontramos en 18.554 aplicaciones Lovable

Nueve comprobaciones, desde fuera, sin inicio de sesión y sin acceso a la cuenta de nadie. Nunca leímos una fila: donde una base de datos respondía, preguntamos cuántas filas entregaría y ahí nos paramos. Ninguna aplicación se nombra aquí ni en nada que publiquemos. Cada proporción de abajo es sobre las aplicaciones donde la comprobación respondió, porque una comprobación que no pudo terminar es desconocida y no aprobada, y esa regla es por la que se mueven los denominadores. El método y los datos están en el informe.

Las notas: 15.963 A, 370 B, 1.814 C, 402 D y 5 F. Nueve aplicaciones no tuvieron ningún hallazgo.

Esa primera fila es la razón por la que "el 99 % de las aplicaciones Lovable tiene un problema de seguridad" es una frase que leerás en algún sitio y deberías ignorar. Las cabeceras de seguridad del navegador las manda lo que sirve tu página, y en tuapp.lovable.app eso es Lovable, por lo que todas las aplicaciones de ese host reciben la misma respuesta. Merece la pena tenerlas y no son de lo que está hecha una D.

Quita esa fila y 15.453 de las 18.554 aplicaciones no tenían nada más. Las 3.092 restantes son el resto de este artículo.

Lo que Lovable hace bien, y es casi toda la lista

Tres de las cifras de arriba son las mejores que hemos anotado en ningún constructor, y las tres las decide la plataforma y no tú.

Los source maps. 225 de 18.553 aplicaciones Lovable publican los archivos originales de detrás, comentarios incluidos. Eso es alrededor de 1 de cada 80. En Base44 la misma comprobación salta en el 59 % de las aplicaciones, y en Replit en el 6 %. El build de producción de Lovable hace lo correcto por defecto, así que esto casi nunca es problema tuyo.

Las cabeceras cross-origin. Cero aplicaciones de 18.518 le dijeron a un sitio cualquiera del mundo que podía llamar a su API, y cero lo permitieron con las cookies de sesión del visitante. Ese es el hallazgo que con más facilidad deja a otro sitio actuar como tu usuario, y en Lovable no apareció ni una vez.

Archivos privados sueltos. Cero aplicaciones de 18.442 servían un .env o un .git/config desde una URL normal. Una aplicación Lovable no tiene servidor propio que configurar mal, así que no hay ningún archivo olvidado detrás.

Nada de esto es un premio de consolación. Es la parte del trabajo en la que no tuviste que pensar y en la que, en la mayoría de los otros constructores, alguien piensa.

La única cifra que importa: 2.017 de 3.553

De las aplicaciones Lovable cuya base de datos Supabase pudimos preguntar de verdad, el 57 % entregó filas a una petición que no llevaba ningún inicio de sesión.

Los denominadores merecen recorrerse, porque esta es la cifra que todo el mundo cita y casi nadie encuadra. De 18.554 aplicaciones Lovable, 6.532 nombraban un proyecto de Supabase en el código que entregan. De esas, 3.553 respondieron lo bastante bien como para poder juzgarlas, y las otras 2.979 no, así que son desconocidas y no limpias. De las 3.553, 2.017 devolvieron filas a un desconocido.

En 373 de esas aplicaciones la tabla que respondió llevaba nombre de personas: users, profiles, orders, messages. Son 373 aplicaciones, no 373 tablas. En las otras 1.644 era algo que no pudimos nombrar desde fuera: quizá un catálogo de productos que siempre debió ser público, quizá cualquier otra cosa.

Medido contra todas las aplicaciones Lovable escaneadas en vez de contra el subconjunto que pudimos juzgar, 2.017 de 18.554 es alrededor de 11 de cada 100. Quédate con esa cifra dos secciones.

Por qué cae en la base de datos y no en Lovable

Por una decisión de diseño que es correcta, deliberada, y que casi nunca se le explica a la persona a la que afecta.

Una aplicación Lovable no tiene servidor propio. La página en el navegador del visitante habla directamente con Supabase, que es por lo que todo esto se puede construir en una tarde y por lo que tan pocas de estas aplicaciones tienen una ruta de API abierta: no hay ninguna API tuya que dejar abierta. Para que eso funcione, la dirección de tu base de datos y una clave para ella tienen que estar impresas dentro de la aplicación, donde cualquiera puede leerlas. Esa clave es la clave publicable, y que sea pública es correcto. Se supone que está ahí.

Lo que significa que lo único que hay entre un desconocido y tu tabla users es un ajuste de Supabase por tabla llamado Row Level Security. Encendido y con una policy escrita, la clave pública lee solo las filas que esa policy permite. Apagado, la clave pública lee la tabla.

Ahora la parte que decide la mayoría de los proyectos Lovable. Supabase enciende Row Level Security por defecto en las tablas que creas haciendo clic en el Table Editor. Las tablas creadas ejecutando SQL no lo reciben, y ejecutar SQL es como un constructor crea tablas para ti. La forma habitual de un proyecto Lovable es por tanto: unas pocas tablas hechas a mano, que están protegidas, al lado de las que se generaron, que puede que no. Las dos se ven idénticas. Ninguna protesta. La aplicación funciona perfectamente en ambos casos, que es todo el problema: nada que veas desde delante te dice cuál de las dos tienes.

La versión larga de esto, con el SQL, está aquí, y la guía en lenguaje llano para esta plataforma es es segura tu aplicación Lovable.

La policy que quita el error y deja la tabla abierta

Encender Row Level Security es el paso uno de dos, y en el paso dos un asistente de IA hace de muy buena gana lo incorrecto.

Con el ajuste encendido y sin policy escrita, tu propia aplicación deja de funcionar. Te sale un error, lo pegas en el chat, y llega algo que hace que el error desaparezca. Muy a menudo lo que llega es una policy que permite a todo el mundo, escrita como using (true). Es una policy válida. Cumple el requisito de que exista una policy. Permite cada fila a cada petición.

El panel ahora informa la tabla como protegida, el error se fue, tu aplicación funciona, y la tabla es exactamente igual de legible que antes. Tenemos un artículo entero sobre esto porque es el fallo más convincente de toda la pila: RLS está encendido y tu tabla sigue siendo pública.

Si alguna vez has pegado un error de Row Level Security en una ventana de chat y aceptado el primer arreglo que hizo que compilara, ve a leer esa policy hoy.

CVE-2025-48757, y por qué ya no es tu pregunta

Es real, fue seria, y por el lado de Lovable lleva más de un año cerrada. Tampoco es lo que deberías estar comprobando.

En mayo de 2025 el investigador de seguridad Matt Palmer publicó CVE-2025-48757, sobre aplicaciones Lovable cuyas tablas de Supabase tenían Row Level Security ausente o escrito con demasiada permisividad. Escaneó 1.645 aplicaciones Lovable y encontró 170 con bases expuestas. La respuesta de Lovable fue añadir una comprobación de seguridad que corre antes de publicar y avisa de las tablas desprotegidas.

Y aquí la lectura honesta, que es por lo que la CVE es el marco equivocado. Aquella divulgación encontró alrededor de 10 aplicaciones expuestas de cada 100. Dieciséis meses después, en una cohorte once veces mayor, encontramos alrededor de 11 de cada 100. Los denominadores no son idénticos y ninguna de las dos muestras es internet entero, así que toma las dos como el mismo orden de magnitud y no como una comparación precisa. La dirección está bastante clara: la tasa no ha bajado.

Eso no es un arreglo que falló. Es una señal de que nunca fue realmente una vulnerabilidad de un producto. Es un ajuste en tus propias tablas, en tu propio proyecto de Supabase, que nadie más puede encender por ti. Un parche no llega ahí, que es exactamente por lo que sí llega una comprobación que lanzas tú.

De qué estaban hechas de verdad las 822 claves

Casi todas estaban bien, y un escáner que te dijera lo contrario te estaría enseñando a ignorarlo.

822 de las 18.554 aplicaciones Lovable tenían algo con forma de clave en el código que descarga un visitante. Leído como una lista de formas, eso es el 4 % de las aplicaciones "filtrando secretos". Leído como lo que cada clave puede hacer de verdad, se ve así:

Las 727 claves de Google son la razón por la que clasificamos en vez de solo reconocer formas. Una clave de Google Maps en un navegador está donde debe estar, y el arreglo es restringirla a tu propio dominio en lugar de entrar en pánico.

Las cuatro últimas filas son las que importan, y son raras: 30 aplicaciones de 18.554. También son los hallazgos que cuestan dinero por sí solos, y suelen salir a la superficie como una factura que llega antes de que nadie se haya dado cuenta. Dos detalles para el acta. Las tres claves service_role de todo el escaneo de 30.998 aplicaciones estaban en aplicaciones Lovable, y dos de los tres secretos de Stripe en vivo también. Una clave service_role en el navegador deja sin efecto cada policy de Row Level Security de tu proyecto en una sola línea, por lo que es el único hallazgo que calificamos de crítico a simple vista y el que merece rotarse el mismo día.

Distinguir las dos clases lleva alrededor de un minuto, y escribimos la guía.

Los 768 buckets de almacenamiento que nadie quiso abrir

Un bucket de Supabase marcado como público no sirve solo los archivos que tu aplicación enlaza. También le lista cada archivo que contiene a cualquiera que pregunte.

768 de las 16.565 aplicaciones Lovable comprobables tenían al menos un bucket que listaba su contenido. La razón es la misma que la de las tablas legibles: hacer público un bucket es como consigues que se vea una imagen, funciona al instante, y después nada te dice que el listado venía incluido. Facturas subidas, fotos de documentos de identidad y avatares de usuarios acaban todos en el mismo sitio. Lo que expone de verdad un bucket público cubre el arreglo, que son URL firmadas y no un bucket privado del que luego no puedas leer.

La comprobación de cinco minutos sobre tu aplicación Lovable

Cada punto es una página que abres. Usa una ventana privada para que tu propia sesión no responda por un desconocido.

1. Supabase → Authentication → Policies. Recorre la lista. Cualquier tabla que muestre Row Level Security desactivado es legible por quien tenga la dirección de tu proyecto, que está impresa en tu aplicación.
2. Lee las policies de las tablas que sí lo tienen encendido. Si una permite a todo el mundo, la tabla está abierta y el panel la sigue llamando protegida.
3. Supabase → Storage. Cualquier bucket marcado como público lista sus archivos a cualquiera. Mira qué hay dentro antes de decidir que está bien.
4. Supabase → Settings → API. Confirma que la clave que entrega tu aplicación es la publicable. Si alguna vez se pegó una clave secreta en el proyecto, rótala ahí antes de borrarla del código, porque el valor antiguo sigue funcionando hasta que lo hagas.
5. O deja que lo haga el escaneo. Lanza esos cuatro desde fuera y cinco más, tarda unos 20 segundos, no pide cuenta, y te enseña una nota y qué la produjo: escanea tu aplicación.

Si prefieres recorrer toda la superficie como una lista, la lista de seguridad de 10 minutos cubre lo que merece confirmarse en cualquier aplicación recién lanzada, y puede cualquiera leer tu base de datos Supabase es la prueba que hay que hacer si solo haces una cosa.

Tu aplicación cambia cada vez que publicas

Un escaneo que lanzaste el mes pasado describe la aplicación del mes pasado, y en Lovable ese es un mes más corto que en otros sitios.

Publicar es un clic, así que un cambio está en vivo en cuanto lo aceptas. No hay ningún paso de despliegue entre tú e internet que atrape una tabla añadida esta mañana con Row Level Security apagado, o una clave pegada en el chat a medianoche para pasar un build que fallaba. Cada una de las 2.017 bases expuestas que encontramos era de alguien cuya aplicación funcionaba perfectamente.

Reeve Monitor es la versión de este artículo que se lanza sola. Repite las nueve comprobaciones cada hora en hasta tres aplicaciones, mira cada 60 segundos si la aplicación responde, te avisa cuando un resultado cambia en vez de esperar a que mires, y manda un informe mensual. Cuesta $12 al mes de tarifa de lista, con siete días gratis antes de cobrarte; la página de precios a veces está por debajo de la cifra de aquí y nunca por encima.

Si tu aplicación Lovable usa Supabase, y 6.532 de las 18.554 escaneadas lo hacen, la otra mitad del problema es la copia. Una tabla expuesta es algo que un desconocido puede leer. Un agente con acceso a la base, o una migración que corrió al revés, es algo que puede borrarla, y la copia de seguridad diaria del propio Supabase en el plan gratuito no es algo que puedas restaurar tú. Reeve Care toma cada noche una copia cifrada de tu base de datos Supabase, la guarda donde tu proyecto no llega, verifica que cada copia se restaura de verdad, y te da una restauración en un clic cuando la necesitas. Incluye todo lo que hace Monitor. Care cuesta $49 al mes de tarifa de lista para una aplicación, con los mismos siete días gratis.

La forma de ese segundo fallo, contada por alguien a quien le pasó, está en el día en que un agente de IA borró una base de datos de producción. Ninguna de las nueve comprobaciones de este artículo habría ayudado ahí. Una copia sí.

Qué hacer esta semana

Lovable hizo bien su mitad. Los 2.017 son la mitad que es tuya, y es un ajuste y no una reescritura. Si lo que quieres es la comparación entre constructores, qué constructor de aplicaciones con IA es el más seguro tiene la tabla de los cinco.