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á: Nurbak prueba tu app de Lovable desde afuera y marca tablas legibles públicamente, claves expuestas y headers faltantes en una pasada. Pegás la URL, informe en segundos.