Auditoría de seguridad de apps Lovable: 10 comprobaciones de Supabase antes de lanzar

Con Lovable puedes pasar de una idea a una app funcionando con usuarios reales en días. La mayoría de apps de Lovable usan Supabase para la base de datos, la autenticación y el almacenamiento de archivos. Esa arquitectura es buena, pero tiene una regla que no puedes saltarte: a la base de datos se llega desde el navegador, así que es la propia base de datos la que debe decidir quién ve qué.

Por qué importa

En 2025 un investigador analizó apps públicas de Lovable e informó de que más de 170 de unas 1.600 exponían datos por una seguridad a nivel de fila ausente o débil. El fallo se registró como CVE-2025-48757. Desde entonces Lovable ha añadido comprobaciones de seguridad, pero la regla de fondo no ha cambiado: cada tabla necesita políticas correctas, y solo tú sabes qué es “correcto” para tus datos.

Las 10 comprobaciones

1. RLS está activada en todas las tablas

En el editor SQL de Supabase, ejecuta:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Todas las filas deben mostrar true. Una tabla sin RLS se puede leer y escribir con tu clave pública.

2. Las políticas restringen, no solo existen

RLS con una política como using (true) equivale a no tener RLS. Busca políticas que liguen las filas al usuario, como auth.uid() = user_id. Ten políticas separadas para select, insert, update y delete, y usa with check en insert y update para que nadie pueda escribir filas a nombre de otro.

3. Prueba como dos usuarios y como nadie

Crea dos cuentas de prueba. Entra como el usuario A e intenta leer, cambiar y borrar registros del usuario B a través de la API, no solo de la interfaz. Después intenta lo mismo solo con la clave pública y sin iniciar sesión. Son 20 minutos y encuentran la mayoría de fugas reales.

4. La clave service-role no está en el frontend

Busca en el JavaScript compilado, en el repositorio y en su historial la clave service-role o secret. Se salta RLS por completo. Solo debe vivir en los secretos de las edge functions. Si alguna vez se subió o se publicó, rótala en Supabase; borrar la línea no basta.

5. Los buckets de storage son privados cuando los archivos lo son

Revisa cada bucket. Facturas, documentos de identidad y archivos subidos por usuarios deben ir en buckets privados, con políticas en storage.objects que limiten el acceso al propietario, y servirse con URLs firmadas.

6. Las edge functions comprueban quién llama

Cada edge function debe verificar el token del usuario y comprobar que puede actuar sobre el registro pedido. Nunca te fíes de un user_id que llega en el cuerpo de la petición. Permite CORS solo desde tus propios dominios.

7. Las vistas y funciones de la base de datos no se saltan RLS

Las vistas de Postgres se ejecutan por defecto con los permisos de su propietario, lo que puede saltarse RLS. Créalas con security_invoker = true. Las funciones marcadas como security definer también corren con permisos elevados: que sean pocas, con un search_path fijo y con comprobación de permisos dentro.

8. La autenticación está lista para un lanzamiento real

Exige confirmación de email, limita las URLs de redirección a tus dominios, pon una longitud mínima de contraseña razonable y activa MFA en las cuentas de administración. Elimina usuarios de prueba y cuentas de ejemplo antes de lanzar.

9. Los endpoints de pago o abusables tienen límites

El registro, el reseteo de contraseña, el envío de emails y cualquier edge function que llame a una API de IA o SMS de pago necesitan límites de peticiones. Si no, un script puede disparar tu factura o hacer que bloqueen tu dominio de correo en una noche.

10. Pasa el Security Advisor de Supabase y revisa las copias

El Security Advisor del panel de Supabase señala tablas sin RLS y vistas y funciones de riesgo. Corrige todo lo que marque. Después comprueba qué copias de seguridad incluye tu plan y si alguna vez has restaurado una.

En qué orden

Haz primero 1–4: deciden si tus datos están expuestos hoy. Después 5–7, y luego 8–10. Apunta qué has comprobado y qué has encontrado; ese registro breve responde a las primeras preguntas de seguridad de cualquier inversor, cliente o socio.

Cuándo pedir una segunda opinión

Si tu app cobra pagos, guarda datos personales de usuarios de la UE o estás a punto de levantar dinero o firmar con un cliente grande, una revisión independiente merece la pena. Nuestra auditoría de seguridad de apps hechas con IA cubre estas comprobaciones y el resto de nuestra lista de 12 puntos para apps hechas con IA, con una corrección concreta para cada hallazgo.