Reeve ¿Es segura tu app de Lovable?
¿Es seguro construir con Lovable? Normalmente sí. Lo que lo decide es un ajuste de la base de datos tomado el día en que se crearon tus tablas.
Los logotipos son propiedad de sus respectivos dueños y se muestran solo para indicar compatibilidad.
En resumen
- Una app de Lovable suele ser segura por el lado del código. Lo que decide si tus datos lo son es un ajuste de Supabase tabla por tabla.
- Encontrar una clave de API en tu app normalmente no es un problema. Una clave publicable pertenece ahí; sb_secret_… o service_role no.
- Supabase activa Row Level Security en las tablas creadas en el Table Editor, pero no en las creadas ejecutando SQL, y así es como un builder las crea.
Lovable te lleva de una idea a una app que funciona más rápido que cualquier otra cosa, y la parte de la que se encarga por ti es justo la que nunca ves: la base de datos, las tablas, las reglas sobre quién puede leerlas. Cuando alguien te dice que tu app de Lovable «está filtrando datos», la respuesta suele estar ahí, y no es un sitio al que puedas asomarte desde el editor.
Aquí está lo que guía tras guía cuenta mal: el riesgo casi nunca es el código que Lovable escribió por ti. Es un único ajuste de base de datos, decidido en el momento en que se creó una tabla, que la mayoría de los artículos se saltan o describen al revés.
Qué construye Lovable en realidad, y qué mitad es pública
Dos mitades, y solo una es privada.
Piénsalo como una tienda. Lovable te construye un escaparate (las páginas, los botones, los formularios), y ese escaparate se le entrega entero a cada visitante. Cualquiera puede leerlo. No es un defecto; un navegador no puede mostrar una página que no le han dado. Detrás del escaparate hay un almacén, tu base de datos de Supabase, que es un edificio aparte con su propia cerradura.
El error que sale caro es suponer que el escaparate manda sobre el almacén. No lo hace. Quitar un botón de tu app es descolgar un cartel, no cerrar una puerta. A tu base de datos se llega directamente, por internet, desde cualquier sitio si se conoce su dirección, y esa dirección está impresa en el escaparate, porque así es como tu propia app habla con ella.
¿Una clave en el código de tu app de Lovable es un problema?
Normalmente no. Depende por completo de qué clave sea, y hay dos tipos que se parecen casi exactamente.
Una clave publicable dice a qué proyecto pertenece una petición y nada más.
Supabase la llama sb_publishable_… en los proyectos nuevos y anon en los
antiguos, y está diseñada para vivir en tu app donde cualquiera puede leerla. Una
clave secreta es lo contrario: sb_secret_…, o service_role en proyectos
antiguos. Ignora todas las reglas que hayas puesto y puede leer y escribir cada
fila de cada tabla.
Las dos están una junto a otra en el panel de Supabase, miden lo mismo y se comportan igual mientras construyes. Copiar la equivocada es un solo clic mal puesto, y después no se rompe nada, y justo por eso pasa desapercibido. Si quieres la versión larga de cómo distinguirlas, hemos escrito una.
Qué decide si un desconocido puede leer tus datos
Row Level Security, un interruptor por tabla en Supabase que decide fila a fila quién puede ver qué. Apagado, tu clave publicable lee la tabla entera. Encendido y con una política escrita, lee solo las filas que esa política permite.
Y ahora la parte que importa específicamente en una app de Lovable. Supabase activa Row Level Security por defecto en las tablas creadas en el Table Editor del panel, el de hacer clic. Las tablas creadas ejecutando SQL no lo reciben activado y hay que encenderlas a propósito.
Ejecutar SQL es como un builder crea tablas por ti.
Así que la forma habitual de un proyecto de Lovable es un puñado de tablas que añadiste haciendo clic, que están protegidas, junto a las tablas que se generaron por ti, que puede que no. Las dos se ven idénticas en el editor. Ninguna se va a quejar. Y activar el ajuste todavía no es la meta, porque una tabla con Row Level Security activado y una política que permite a todo el mundo está abierta de una forma que se lee como cerrada.
Cómo revisar tu propia app de Lovable en unos diez minutos
Abre Supabase y ve a Authentication → Policies. Recorre la lista de tablas. Todo lo que aparezca con Row Level Security desactivado lo puede leer cualquiera que tenga la dirección de tu proyecto, que es pública.
Comprueba la clave que envía tu app. En Supabase, entra en Settings → API. Si la clave que usa tu app es la publicable, es lo correcto y no hay nada que hacer. Si alguna vez se ha pegado una clave secreta en tu proyecto de Lovable, renuévala ahí primero: borrarla del código no cierra la puerta, porque el valor antiguo sigue existiendo en las copias en caché de tu web.
Mira tus buckets de almacenamiento. Todo lo marcado como público lo puede listar y descargar cualquiera, enlace o no tu app hacia ello.
Y luego mira desde fuera. Las comprobaciones de arriba te dicen qué está configurado; no te dicen a qué llega de verdad un desconocido. Ese hueco lo cubre nuestro escaneo gratuito: lee tu web en vivo igual que lo haría cualquier visitante y te da una nota en unos 20 segundos, sin cuenta: escanea tu app.
Qué hacer
- El escaparate es público por diseño. Todo lo que Lovable envía a un navegador lo puede leer cualquiera, y esconderlo no cambia nada.
- Una clave publicable en tu app es correcta. Una clave secreta (
sb_secret_…oservice_role) es la que hay que renovar hoy. - Las tablas hechas en el Table Editor de Supabase llevan Row Level Security activado por defecto. Las creadas ejecutando SQL no, y así es como las hace un builder.
- Activar Row Level Security es el paso uno. Una política que permite a todos deja la tabla abierta mientras el panel la muestra como protegida.
- Quitar una pantalla o un botón de tu app de Lovable no cambia nada de lo que tu base de datos va a responder.
Lo más rápido y útil que puedes hacer hoy es abrir Authentication → Policies en Supabase y leer la lista. Si alguna tabla dice que Row Level Security está desactivado, empieza por esa, y si prefieres recorrer toda la superficie como una lista, la lista de seguridad en 10 minutos cubre el resto.
Qué puede salir mal de verdad con una app de Lovable
Nada de esto significa que hayas hecho algo mal. Son los efectos secundarios normales de construir rápido. Estos son los que vale la pena comprobar:
Una clave secreta enviada al navegador
Una «clave secreta» es la contraseña maestra de un servicio que usas: tu base de datos, una herramienta de correo, una API de IA. Se supone que vive en un servidor. A veces una se cuela en el código que se ejecuta en el navegador de tu visitante, donde cualquiera puede leerla, y alguien podría usarla para llegar a tus datos o generar gastos a tu nombre. El matiz: algunas claves se supone que deben ser públicas (Lovable y Supabase las llaman claves «publishable» o «anon»), y esas están bien. Reeve conoce la diferencia, así que una clave segura nunca dispara una falsa alarma.
Tu base de datos abierta (RLS de Supabase desactivado)
Las apps de Lovable suelen guardar los datos en Supabase. Supabase tiene un interruptor de seguridad llamado Row Level Security (RLS) que decide quién puede leer o cambiar cada fila. Si está desactivado, tus tablas pueden ser legibles, o editables, por cualquiera que encuentre la dirección. Es la diferencia entre «mis datos son míos» y «mi lista de clientes es pública», y es el problema más común en apps hechas con vibe coding.
Un archivo .env o de configuración expuesto
El archivo .env es donde un proyecto guarda sus contraseñas y claves. De vez en cuando se publica por error junto con la app. Si es accesible, es un atajo directo a todo lo sensible. Reeve comprueba si el tuyo está accesible sin que lo sepas.
Almacenamiento de archivos público
Si tu app permite subir archivos (fotos, PDF), estos viven en «buckets» de almacenamiento. Un bucket dejado público significa que cualquiera puede navegar o descargar lo que hay dentro, así que una subida pensada para una persona puede acabar visible para todos. Reeve comprueba si tus buckets son listables; nunca descarga los archivos de nadie.
Source maps dejados activos
Un «source map» es un archivo entre bastidores que revela el código original de tu app. Útil mientras construyes, pero si llega a producción entrega a extraños una copia legible de cómo funciona tu app, lo que hace más fácil de encontrar cada puerta de arriba. No es urgente por sí solo, pero conviene ordenarlo.
Cabeceras de seguridad ausentes y endpoints abiertos
Pequeños ajustes que le dicen a los navegadores cómo proteger a tus visitantes, más si los endpoints de datos de tu app responden a cualquiera o a cualquier sitio. Individualmente menores; juntos amplían la brecha. Reeve señala los que faltan.
Qué es Reeve, y qué no
Reeve es una comprobación gratuita, de solo lectura y desde fuera, como un inspector que rodea el edificio y prueba las puertas. Es rápida y detecta los errores comunes de alto impacto. No es una auditoría de seguridad completa, y una nota limpia no es garantía. Significa que las puertas obvias están cerradas.
Lovable es una herramienta capaz, y su equipo añade sin parar barandillas de seguridad; Supabase también tiene un asesor integrado que señala problemas de RLS en su panel. Ambos son de verdad útiles. Lo que Reeve añade: tú vives en Lovable, no en la consola de Supabase, y esas herramientas hablan en lenguaje de desarrollador. Reeve mira toda tu app desde fuera, como lo haría un extraño, y te dice lo que encuentra en palabras con las que puedes actuar. Y si prefieres no pensar en ello en absoluto, podemos vigilarla por ti.
¿Quieres que se gestione, no solo que se compruebe?
Reeve Care sigue vigilando tu app, respalda tus datos y te ayuda a arreglar cosas cuando se rompen, para que puedas seguir creando en vez de preocuparte.
Conoce Reeve CarePreguntas frecuentes
¿Mi app de Lovable es segura por defecto?
Lovable te da un punto de partida sólido y mejora sin parar sus ajustes por defecto, pero «seguro por defecto» aún depende de cómo esté configurada tu app, especialmente de las reglas de tu base de datos en Supabase. La única forma de saberlo es comprobar qué está realmente expuesto, que es lo que hace el análisis gratuito de Reeve en unos 20 segundos.
¿Puede una app de Lovable filtrar mis claves de API?
Puede pasar, normalmente cuando una clave que corresponde a un servidor acaba en el código del front-end. Pero no toda clave es un problema: algunas están diseñadas para ser públicas. Reeve lee el código cargado de tu app, encuentra todas las claves y te dice cuáles son seguras y cuáles deben moverse.
¿Qué es el RLS de Supabase y por qué importa para mi app de Lovable?
El RLS (Row Level Security) es la regla de Supabase sobre quién puede ver o cambiar cada fila de tus datos. Si está desactivado, tus tablas pueden estar abiertas para cualquiera. Como la mayoría de las apps de Lovable usan Supabase, es lo más importante que hay que acertar, y Reeve lo comprueba sin leer nunca tus datos reales.
¿Analizar mi app de Lovable romperá algo o cambiará mis datos?
No. Reeve solo mira lo que ya es público desde fuera. Nunca inicia sesión, nunca cambia nada y nunca descarga tus archivos. Solo lectura, como comprobar si una puerta está cerrada sin entrar.
Lovable me creó la base de datos. ¿Significa que está configurada de forma segura?
No automáticamente, y el motivo es concreto. Supabase activa 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 builder crea tablas por ti. Así que las tablas que hiciste a mano suelen estar protegidas y las que hizo Lovable puede que no.
¿Cuáles de mis tablas tienen Row Level Security activado?
Abre tu proyecto de Supabase, ve a Authentication y luego a Policies. Ahí aparece cada tabla de tu esquema public con el estado de RLS. Todo lo que figure como desactivado lo puede leer cualquiera que tenga la dirección de tu proyecto y tu clave publicable, y ambas cosas están dentro de tu app.
He encontrado una clave en mi app de Lovable. ¿Cómo sé si importa?
Mira de qué tipo es. Una clave publicable (llamada sb_publishable_ en los proyectos nuevos de Supabase, o anon en los antiguos) pertenece al navegador y no es una filtración. Una clave secreta, sb_secret_ o la antigua service_role, ignora todas las reglas que pongas y nunca debería llegar a un navegador. Si encuentras esa, renuévala en el panel de Supabase antes que nada.