Checklist de seguridad para apps de Lovable: ¿es segura su app?

¿Es Lovable seguro, y eso hace segura mi app?

Lovable dice que cumple los requisitos de SOC 2 y del RGPD y publica su documentación de seguridad en su centro de confianza. Eso cubre la plataforma de Lovable: su infraestructura, sus controles de acceso, su personal. No cubre las reglas dentro de su app, porque esas las escribió usted (con la ayuda de Lovable).

El análisis de seguridad de Lovable hace una comprobación rápida cada vez que publica: una revisión de la base de datos, una auditoría de dependencias y una comprobación del servidor MCP. Un análisis más profundo, que se inicia a mano (o de forma programada, para clientes de Lovable Enterprise), revisa además el control de acceso, los endpoints sin autenticación, las inyecciones, los secretos filtrados, los pagos, la autenticación y los datos personales expuestos. La propia documentación de Lovable deja claro que estas herramientas no pueden garantizar una seguridad completa. Trate el análisis como un detector de humo, no como una inspección.

¿Qué fue CVE-2025-48757 y afecta a mi app?

CVE-2025-48757, publicada en mayo de 2025, describe políticas de seguridad a nivel de fila insuficientes en sitios generados por Lovable hasta el 15 de abril de 2025, que permitían a atacantes sin autenticar leer o escribir tablas de la base de datos. La National Vulnerability Database de EE. UU. la recoge con una puntuación CVSS 3.1 crítica de 9,3 y señala que Lovable la disputa, alegando que cada cliente es responsable de proteger los datos de su propia app.

El investigador que la notificó, Matt Palmer, dice que analizó 1.645 proyectos y encontró 303 endpoints vulnerables en 170 de ellos, y que Lovable lanzó su análisis de seguridad con Lovable 2.0 en abril de 2025. Opine lo que opine sobre la disputa, la lección práctica es la misma: si su app se generó antes de esa fecha, o si ha cambiado tablas desde entonces, revise usted mismo sus políticas. Que una política exista no es lo mismo que una política correcta.

¿Qué debe cubrir una checklist de seguridad para Lovable?

¿Cómo corrijo errores de RLS de Supabase en una app de Lovable?

Los errores de RLS son de dos tipos opuestos, y conviene saber cuál tiene.

• Permiso denegado (error 42501 de Postgres, o un resultado vacío). RLS está activado y ninguna política permite la petición. Eso es RLS funcionando. Escriba la política más estrecha que permita funcionar a la función, por ejemplo, las filas en las que la columna del propietario coincide con el ID del usuario con sesión iniciada.
• Todo funciona para todo el mundo. El caso más peligroso. Una política como USING (true), o RLS sin activar, deja pasar a cualquier usuario. El asesor de Supabase señala las políticas permisivas (regla 0024, permissive_rls_policy) y las políticas que existen con RLS desactivado (regla 0007, policy_exists_rls_disabled).
• Políticas que leen metadatos del usuario. Supabase desaconseja basar políticas en metadatos que el propio usuario puede editar (regla 0015, rls_references_user_metadata). Use en su lugar una tabla que controle su servidor, como una tabla de miembros del equipo.

Cuando pida a Lovable que corrija una política, vuelva a hacer la prueba de los dos usuarios después. Un prompt que hace desaparecer un error puede conseguirlo ampliando el acceso, que es exactamente el fallo que intenta evitar.

¿Qué claves se pueden exponer en una app de Lovable?

La documentación de Supabase dice que la clave publicable (anon) se puede exponer, porque solo llega a lo que permite la seguridad a nivel de fila. Una clave secreta, incluida la clave service role, se salta todas las políticas RLS y nunca debe estar en un navegador, en una app publicada ni en el control de versiones. La entrada del glosario sobre la clave anon y la clave service role explica la diferencia. Los secretos de terceros, como las claves de Stripe o del proveedor de correo, van en los secretos de las edge functions, no en el código de la app. Vea gestión de secretos.

¿Cada cuánto hay que volver a revisar una app de Lovable en producción?

Tras cada cambio que afecte a datos, accesos o pagos, y de forma periódica para todo lo demás: las dependencias reciben nuevas vulnerabilidades, las claves deben rotarse y las tablas nuevas llegan con políticas nuevas. Por eso la seguridad funciona mejor como hábito que como auditoría. En nuestros planes, los controles de seguridad, la revisión de código y las pruebas de regresión se ejecutan en cada cambio antes de que llegue a producción, y lo aprueba un ingeniero distinto del autor.