¿Es seguro Lovable para una app con clientes reales? Lo que protege solo y lo que te toca a ti

La respuesta corta

Lovable no es inseguro por sí mismo. Las apps que crea tienen tres partes: la web que ve el usuario (se ejecuta en su navegador y cualquiera puede leer su código), unas funciones que se ejecutan en el servidor (Edge Functions) y una base de datos PostgreSQL basada en Supabase. La propia documentación de Lovable lo resume así: lo que está en el navegador es público y nunca debe darse por fiable; quien decide qué datos puede ver cada persona es la base de datos, con sus reglas de acceso.

El problema aparece cuando esas reglas faltan o están mal escritas. Entonces la app funciona perfectamente en la pantalla, pero alguien con conocimientos básicos puede pedir a la base de datos, directamente, los datos de todos tus usuarios. Lovable lo deja claro en su página de seguridad: tú eres responsable de que tu app cumpla los requisitos de seguridad que le corresponden, sobre todo si maneja datos sensibles.

Qué hace Lovable por ti

A septiembre de 2026, esto es lo que Lovable revisa o protege sin que tengas que pedirlo, o con un clic:

• Una revisión rápida (Quick scan) cada vez que abres el diálogo de publicar. Mira las reglas de acceso de la base de datos (tablas sin control por fila, reglas que dejan pasar a todo el mundo), la protección de contraseñas y las librerías con fallos conocidos.
• Una revisión a fondo (Deep scan) que lanzas desde la vista Security del proyecto. Busca en el código fallos de permisos, funciones que se pueden llamar sin iniciar sesión, inyección de datos, claves escritas en el código, trucos para manipular pagos y datos personales que se cuelan en errores o registros. Las dos revisiones son gratuitas.
• Correcciones automáticas de algunos hallazgos críticos recientes de base de datos y de librerías, que se activan por espacio de trabajo o por proyecto. Corregir desde la vista Security con Try to fix all usa un cupo de 10 correcciones gratuitas, compartido con la corrección de errores de compilación; cada una vuelve a estar disponible 24 horas después de usarla.
• Un ajuste para impedir publicar mientras haya problemas críticos sin resolver. Sin él, puedes publicar igualmente, aunque Lovable lo desaconseja.
• Gestión de claves (Secrets). Si pegas una clave de API en el chat, Lovable la reconoce y te propone guardarla como secreto: se guarda cifrada, solo llega a las funciones del servidor y nunca al navegador. Una vez guardada no se puede volver a ver, solo sustituir o borrar.
• Un ajuste para rechazar contraseñas que ya aparecen en filtraciones conocidas (la comprobación HIBP).

Por qué el escáner no basta

En marzo de 2025, el investigador Matt Palmer analizó 1.645 apps hechas con Lovable y encontró 170 proyectos (alrededor del 10 %) con 303 puntos de acceso a datos mal protegidos: emails, nombres, teléfonos, claves de API de otros servicios y datos de pagos y suscripciones. Solo miró la página de inicio de cada app, sin entrar en zonas con contraseña. El fallo se publicó como CVE-2025-48757 en mayo de 2025, y la causa eran reglas de acceso insuficientes en la base de datos. En octubre de 2025, la empresa de seguridad Escape revisó más de 5.600 apps hechas con herramientas de IA (unas 4.000 de Lovable) y encontró más de 2.000 vulnerabilidades, más de 400 claves expuestas y 175 casos de datos personales accesibles.

Desde entonces Lovable ha ampliado mucho sus revisiones. Pero un escáner no conoce las reglas de tu negocio: sabe si una tabla tiene reglas, no si un cliente de tu clínica debería ver solo sus citas o también las de su familia. Una regla puede existir y estar mal. Lovable lo reconoce: sus revisiones no sustituyen una revisión de seguridad completa.

Reglas de acceso (RLS) en cada tabla

La seguridad a nivel de fila (Row Level Security, RLS) es lo que hace que cada usuario vea solo sus datos. Supabase lo explica sin rodeos: una tabla expuesta sin RLS la puede leer y modificar cualquier rol que tenga permiso sobre ella, y en muchos proyectos el rol de los visitantes anónimos lo tiene de entrada. Activar RLS sin escribir ninguna regla bloquea el acceso; activarla con reglas mal escritas da una falsa sensación de seguridad.

Tres trampas habituales, según la documentación de Supabase:

• Una regla del tipo "using (true)" para visitantes anónimos deja leer todas las filas a cualquiera. Solo vale para datos que de verdad son públicos, como un catálogo.
• Sin sesión iniciada, la función que devuelve el usuario actual (auth.uid()) da un valor vacío. Una regla bien escrita lo comprueba explícitamente.
• Las vistas (views) creadas con el usuario administrador se saltan las reglas de las tablas que consultan. Una vista sobre una tabla protegida puede entregar justo las filas que la tabla ocultaba.

Las claves que viajan en el navegador

Tu app lleva dentro una clave de Supabase, la publicable (antes llamada anon). Es normal y está pensada para ser pública: su poder depende por completo de tus reglas RLS. Si las reglas están bien, verla no sirve de nada; si están mal, esa clave basta para leer tus tablas. El análisis de Escape encontró claves de este tipo en el código de muchas apps, junto a reglas mal configuradas: el fallo no era la clave, eran las reglas.

La otra clave, la secreta (antes service_role), es otra cosa: se salta todas las reglas RLS. Supabase insiste en que nunca debe estar en un navegador, en una app publicada ni en el código que subes a GitHub. Lo mismo vale para las claves de Stripe, de OpenAI o de cualquier servicio que te cobre por uso: Lovable considera comprometida cualquier clave que acabe en el código de la web. A septiembre de 2026, Supabase ha anunciado que retirará las claves antiguas (anon y service_role) a finales de 2026, así que si tu app usa su propio proyecto de Supabase conviene pasar ya a las nuevas.

Inicio de sesión y roles

Lovable lo resume en una frase: todas las decisiones de acceso deben tomarse en el servidor, no en el navegador. Ocultar el botón de administración a quien no es administrador está bien para la pantalla, pero no protege nada: cualquiera puede llamar a la base de datos o a tus funciones sin pasar por ese botón.

Cuidado también con dónde se guarda el rol de cada usuario. Supabase advierte que los metadatos de usuario (user_metadata) los puede modificar el propio usuario, así que no sirven para decidir quién es administrador. El rol debe estar en un sitio que el usuario no pueda cambiar: los metadatos de la app (app_metadata) o una tabla propia protegida con RLS.

Pagos y webhooks

Si cobras con Stripe, la regla de oro es que tu app no dé nada por pagado porque el usuario llegue a la página de gracias. Stripe lo explica: no se puede confiar solo en esa página, porque el cliente puede pagar y perder la conexión antes de verla. Lo fiable es el aviso que Stripe envía a tu servidor (webhook) cuando el pago se confirma.

Y ese aviso hay que comprobarlo: Stripe firma cada webhook y tu función debe verificar esa firma con el secreto del punto de conexión (el que empieza por whsec_) antes de activar nada. Si no, cualquiera podría enviar a esa dirección un falso "pago completado".

Archivos, límites de uso y copias de seguridad

Tres cosas que no se ven hasta que fallan:

• Archivos. En Supabase, un contenedor de archivos (bucket) público deja descargar cualquier archivo a quien tenga el enlace. Las facturas, los DNI o las fotos de clientes van en contenedores privados, con reglas que digan quién puede subir, ver o borrar cada archivo.
• Límites de uso. Supabase limita por defecto el inicio de sesión: por ejemplo, 30 registros o accesos cada 5 minutos y 2 emails por hora con su servidor de correo incluido. Tus propias funciones, como la que llama a una IA de pago o envía mensajes, necesitan su propio límite para que nadie las llame miles de veces a tu costa; Supabase documenta cómo añadirlo con Upstash Redis.
• Copias de seguridad. Con Lovable Cloud puedes restaurar copias desde la sección Database. Si tu app usa tu propio Supabase, el plan gratuito no hace copias automáticas (Supabase recomienda exportar los datos tú mismo) y el plan Pro guarda las de los últimos 7 días.

La lista que puedes seguir tú

Antes de invitar a clientes reales, o hoy mismo si ya los tienes:

1. Abre la vista Security de tu proyecto, lanza la revisión rápida y la revisión a fondo, y resuelve todo lo crítico.
2. Activa el ajuste que impide publicar con problemas críticos.
3. Comprueba que todas las tablas con datos de usuarios tienen RLS activada y lee cada regla: busca las que dejan pasar a todo el mundo.
4. Crea dos cuentas de prueba e intenta ver, con la segunda, los datos de la primera. Si puedes, algo está mal.
5. Busca en el código de la web (y en GitHub, si lo sincronizas) cualquier clave que no sea la publicable de Supabase. Si aparece una, cámbiala en el servicio correspondiente y guárdala como secreto.
6. Comprueba dónde se guarda el rol de administrador y que la comprobación se hace en la base de datos o en el servidor, no solo en la pantalla.
7. Si cobras, confirma que el pago se marca como completado desde el webhook y que la firma se verifica.
8. Revisa qué contenedores de archivos son públicos y si algo de lo que guardan debería ser privado.
9. Pon un límite de uso a las funciones que cuestan dinero o envían mensajes.
10. Averigua cómo restaurarías tus datos mañana si algo se borra, y prueba a hacerlo una vez.

Cuándo pedir una revisión

Si tu app guarda solo emails de una lista de espera, la lista anterior y los escáneres de Lovable pueden bastarte. Pide que alguien la revise cuando guardes datos de salud, documentos de identidad o datos de menores; cuando cobres dentro de la app; cuando haya varios tipos de usuario (clientes, empleados, administradores) que deban ver cosas distintas; o cuando no tengas claro qué hacen las reglas que Lovable ha escrito por ti. Una regla mal escrita no da ningún aviso: la app funciona igual.

Qué hago yo en Omplia

Reviso apps hechas con Lovable antes de que tengan clientes, o cuando ya los tienen: reglas RLS tabla por tabla con cuentas de prueba, claves, roles, pagos, archivos y copias de seguridad. Te dejo por escrito qué he encontrado y qué he cambiado. Si tu app ya está bien, te lo diré.

Una app desde 2.900 €, más un plan de mantenimiento mensual opcional. El precio final depende de lo que haya que hacer y queda fijado por escrito antes de empezar. La primera revisión de tu enlace es gratis.