Antes de lanzar una app hecha con Lovable: lista de seguridad previa al lanzamiento

Lovable lleva una app de la idea al producto funcionando más rápido que cualquier herramienta anterior. También ayuda con la seguridad: busca problemas habituales en la base de datos antes de cada publicación y ofrece una revisión más profunda del código hecha con IA. Usa las dos. Detectan mucho, y el propio Lovable dice que no pueden garantizar que una app sea segura.

El hueco está en lo que un escáner no puede saber: qué datos de tu app son privados, quién debería poder hacer qué y qué pasa cuando alguien usa la app de una forma que no previste. Esta lista cubre esa parte. Recórrela una vez antes del lanzamiento, y otra después de cualquier cambio grande.

Base de datos #

1. Row Level Security está activado en todas las tablas. Las tablas creadas por SQL, que es como las crean las herramientas de IA, no lo traen activado. La revisión de Supabase en 10 minutos muestra cómo listarlas.

2. Ninguna tabla privada tiene una regla que lo permite todo. Una regla using (true) en profiles, orders o messages significa que cualquiera puede leerlas, con RLS o sin él.

3. Los usuarios no pueden ascenderse a sí mismos. Si la tabla profiles tiene una columna role, is_admin o plan y los usuarios pueden actualizar su propia fila, también pueden cambiar esa columna, desde el navegador, con una sola solicitud. Guarda los roles y el estado de pago en una tabla aparte que solo escriba el código de servidor, o limita qué columnas permite la regla de actualización.

select table_name, column_name
from information_schema.columns
where table_schema = 'public'
  and column_name ~* '(role|admin|plan|credits|verified|status)';

Compara el resultado con tus reglas de update de la revisión de RLS.

Claves #

4. Ninguna clave secreta en el frontend. Busca sb_secret_ y service_role en la app publicada. Si encuentras una, sigue el plan de la primera hora para una clave secreta filtrada.

5. Tampoco secretos de terceros en el frontend. Las claves de IA, de pagos y de correo van en funciones de servidor. Busca sk-, sk_live, re_ y revisa cada variable de entorno que empiece por VITE_. Cómo llevarlas a una función en el servidor.

Storage #

6. Los archivos personales están en buckets privados. Los avatares pueden ser públicos; los documentos de identidad, las facturas y los contratos, no. Cada usuario debe llegar solo a su propia carpeta. La revisión de Storage.

7. Los buckets tienen límites de tamaño y de tipo. Si no, cualquiera que pueda subir archivos puede guardar lo que sea, a tu costa.

Inicio de sesión #

8. La confirmación por correo está activada, salvo que tengas un motivo para desactivarla. Sin ella, alguien puede registrarse con la dirección de otra persona.

9. Las URL de redirección se limitan a tus dominios. En Supabase, en Authentication → URL Configuration, pon como Site URL tu dominio de producción y añade solo las direcciones que usas. Elimina localhost y las direcciones de vista previa que ya no necesites.

10. El registro está cerrado si la app es solo por invitación. Una herramienta interna con registro abierto es una app pública.

11. Cada página de administración comprueba el rol en el servidor. Ocultar un botón no es control de acceso. Si una página o acción es para administradores, los datos que hay detrás deben estar protegidos por una regla o una función de servidor que compruebe el rol, para que llamar directamente a la API no devuelva nada.

Pagos y funciones #

12. Los precios se deciden en el servidor. El navegador dice qué se compra; el servidor busca el precio. Una función que acepta un importe desde el navegador acabará recibiendo 0.01.

13. Los webhooks de pago se verifican por firma. Un endpoint de webhook que confía en cualquier solicitud permite a cualquiera marcar un pedido como pagado.

14. Las Edge Functions comprueban quién las llama. Cada función que lee datos, gasta dinero o envía correos debe verificar al usuario y validar lo que recibe. Una sola función abierta deshace todas las reglas de tu base de datos.

Recuperación #

15. Sabes cómo restaurarías los datos de ayer. Abre Database → Backups en Supabase y mira qué incluye tu plan; en los planes más bajos puede ser poco o nada. Una edición equivocada de la IA o una mala migración puede borrar una tabla. Si los datos importan, ten copias que hayas restaurado de verdad al menos una vez, en un proyecto de prueba.

Después del lanzamiento #

La seguridad no queda hecha para siempre. Cada nuevo prompt puede añadir una tabla sin reglas, una clave en el sitio equivocado o una función que confía en el navegador. Dos hábitos ayudan:

• Ejecuta el escaneo de Lovable y el Security Advisor de Supabase después de cada cambio importante, no solo en el lanzamiento.
• Pide a la IA, con palabras sencillas, que te explique las reglas de RLS y las funciones que acaba de crear. Si la explicación no coincide con lo que quieres, es momento de mirar más de cerca.

Si quieres un segundo par de ojos antes del lanzamiento, nuestro Security Check gratuito revisa estos puntos desde fuera, en modo de solo lectura, y te envía por escrito los problemas más graves en un máximo de 48 horas. Cuando algo necesita arreglo, el Security Fix se encarga a precio fijo, presupuestado antes de empezar cualquier trabajo.