Lovable convierte un prompt en una app full-stack desplegada, normalmente React en el front y Supabase para auth y datos. Esa magia de punta a punta es por qué es popular, y también por qué su riesgo de seguridad se concentra en un lugar: la base de datos.
El riesgo de Lovable en una frase
Una app de Lovable habla con Supabase directo desde el navegador con la clave anon (pública). Eso está bien, siempre que Row Level Security esté activado con políticas correctas en cada tabla. Si no, cualquiera que abra tu app lee y escribe toda tu base de datos.
Investigadores de seguridad reportaron públicamente gran cantidad de apps hechas con Lovable exponiendo datos por exactamente este hueco: RLS apagado y nada que impida consultar cada fila. Es la fuga de datos clásica del vibe coding.
Qué verificar antes de lanzar
- RLS en cada tabla. Lo más importante. Las tablas nuevas vienen sin RLS. Activalo y agregá políticas, ver la guía de Supabase RLS.
- Solo la clave anon en el frontend. La service-role saltea RLS; nunca debe llegar al navegador. Si llegó, rotala ya.
- Auth realmente obligatoria. Confirmá que páginas y acciones protegidas rechazan a usuarios deslogueados.
- Buckets de storage no públicos. Los archivos subidos no deberían ser legibles por cualquiera con la URL.
Cómo verificarlo rápido
Logueate como un usuario de prueba e intentá leer el registro de otro cambiando el ID: si obtenés sus datos, RLS está roto. O automatizá: sincronizá tu proyecto de Lovable con GitHub y Nurbak escanea el repo, marca tablas sin policies de RLS, chequeos de auth faltantes y claves expuestas en el código o en el historial de git, y puede abrir un PR con el fix. El primer scan es gratis.