Fix: Lovable × seguridad
Tu app de Lovable shippeó rápido.
Sus datos pueden estar shippeando también.
Un escaneo público halló 303 endpoints públicamente accesibles en 170 sitios hechos con Lovable, filtrando datos personales, datos de pago y API keys. Eso no es motivo para tirar lo que construiste — el frontend suele estar bien. Es motivo para ponerle abajo un backend donde el tenant isolation, las sesiones y los secrets los enforza código que nunca tuviste que acordarte de escribir.
El problema no es Lovable. Es todo lo que Lovable te deja a vos.
Lovable genera un frontend React pulido cableado a Supabase — o sea que todo el modelo de seguridad de tu app vive en políticas de Row Level Security que la IA puede haber escrito o no, y que quizás ni sabés que existen. El escaneo del investigador de seguridad Matt Palmer sobre 1.645 apps hechas con Lovable encontró 170+ con la base de datos totalmente legible por cualquiera, y una auditoría de vibe-eval.com encontró que el 90% de las apps escaneadas comparte las mismas cinco vulnerabilidades. El patrón fue tan grave que se ganó su propio CVE (CVE-2025-48757). Un desarrollador con 20+ años de experiencia posteó en r/lovable una carta abierta sobre la seguridad de las apps de Lovable y juntó 620+ upvotes — la comunidad lo sabe. La parte incómoda: pediste features, y te las dieron. Nadie pidió la política de seguridad de cada tabla, así que nadie la escribió.
Cinco cosas para revisar hoy en tu app de Lovable
RLS desactivado o abierto por default
Abrí Supabase → cada tabla → mirá Row Level Security. Si está apagado, cualquier fila se puede leer con la anon key que viaja en tu frontend. Esta fue la causa raíz en la mayoría de las apps Lovable expuestas.
Keys visibles en el bundle
Abrí tu sitio deployado, mirá el código fuente y buscá 'sk_', 'service_role' y 'api_key'. Todo lo que encuentres, un atacante lo encontró primero. Rotá ya — borrar el código no des-filtra la key.
La anon key haciendo trabajo privilegiado
Si alguna llamada client-side inserta, actualiza o borra sin una política RLS que la scopee al usuario logueado, cualquier visitante puede hacer lo mismo con curl. Que la UI esconda el botón no es control de acceso.
Edge functions sin checks de auth
Las edge functions que genera Lovable suelen confiar en que solo tu frontend las llama. Son URLs públicas. Cada una tiene que verificar el JWT de quien llama antes de tocar datos.
Flujos de auth que nadie testeó más allá del happy path
El sign-up anda. ¿Pero el reset de contraseña invalida el link después de usarlo? ¿La sesión de un usuario borrado sigue pudiendo llamar a la API? Esas son las preguntas que ningún prompt hizo.
Cómo se ve una pared cuando no te podés olvidar de construirla
En useDeploy, el tenant isolation no es una política que escribís por tabla — es la capa de repositorios misma. Cada repo está scopeado por organización y un query guard de Prisma chequea la organización en cada query. Un request por el recurso de otra org no recibe un error de permisos que confirma que el recurso existe. Recibe un 404, como si nunca hubiera existido.
1 $ curl api.yourapp.com/api/orgs/org_b/projects # la sesión es de org_a
2 HTTP/1.1 404 Not Found
3 { "error": "Not found" }
4
5 # log del server
6 WARN tenant-guard: session org_a requested resource in org_b
7 INFO responded 404 — existence not disclosed
8
9 # no hay política RLS que olvidar. el guard corre en cada query.
Ya cerrado en la base
Tenant isolation sin RLS
Repositorios org-scoped más un query guard de Prisma hacen que el acceso cross-org devuelva 404 por construcción. No hay checklist de políticas por tabla, así que no hay política que se te escape.
Sesiones que viven server-side
Las sesiones son filas en Postgres, revocables a voluntad — no tokens que el cliente retiene para siempre. Cerrar las sesiones concurrentes al cambiar una credencial es un flag documentado que prendés, no un rewrite.
Los secrets nunca llegan al navegador
Cada secret vive en variables de entorno validadas por un schema de Zod al boot. Si falta un secret requerido, el server se niega a arrancar — y nada secreto se bundlea jamás del lado del cliente.
Auth que es más que un formulario
2FA TOTP, magic links y OAuth vienen cableados vía BetterAuth, con rate limiting en los endpoints de auth por IP y por email, así el credential stuffing choca contra una pared.
Evidencia, no vibes
450+ tests automatizados y un gate E2E de Playwright en CI hacen que los comportamientos de seguridad de arriba se ejerciten en cada merge — incluido el 404 cross-org.
Ruta de migración: quedate con el frontend, reconstruí el piso
Lovable sincroniza tu proyecto a GitHub, así que empezá exportando el repo — tus componentes React, páginas y estilos sobreviven casi enteros. Lo que cambia es con qué hablan. Las llamadas directas a Supabase desde el navegador se vuelven llamadas a una API tipada: useDeploy expone cada endpoint a través de tipos OpenAPI generados, así que tus componentes fetchean por un cliente que atrapa el drift en compile time. El auth pasa de Supabase Auth a BetterAuth (sesiones por cookie, 2FA y OAuth incluidos), y tus tablas se mudan a un schema de Prisma donde el tenant guard scopea cada query. Hacelo pantalla por pantalla: apuntá una página a la API nueva, verificá, seguí. La app que ven tus usuarios casi no cambia. La parte que no podían ver — la que estaba filtrando — es la que se reemplaza.
Lovable × seguridad, sin vueltas
¿Puedo quedarme con mi frontend de Lovable?+
¿Igual tengo que aprender RLS?+
¿Qué pasa con mis datos actuales en Supabase?+
¿Cómo sé que la base en sí es segura?+
Una licencia. Dos formas de tenerla.
CORE
Founder
Un snapshot congelado de UseDeploy. Tuyo para siempre, sin updates.
- Descarga del zip con versión frozen
- Código completo, uso comercial, proyectos ilimitados
- Los 800+ tests · todas las páginas de docs
- Refund a 14 días
LATEST + UPDATES
Lifetime
Siempre el último UseDeploy. Re-descargá cada release, gratis.
- Zip de la última versión — re-descargable para siempre
- Cada release futuro sin cargo extra
- Soporte Discord priority
- Los 800+ tests · todas las páginas de docs
- Refund a 14 días
Dale a tu app el backend que se merecía
Validaste el producto en días. Ahora ponele un piso: tenant isolation, sesiones server-side y secrets validados — ya construido, ya testeado.