¿Es segura mi app de Lovable? Qué suele filtrarse y cómo revisarlo

Todo lo que tu app le manda al navegador —el HTML y el JavaScript— es público. Cualquiera lo puede abrir con las herramientas de desarrollador del navegador; no hace falta ser hacker. Si desde ahí se llega a una clave secreta o a una base de datos abierta, un desconocido la puede usar: gastarte la cuenta de IA o de emails, leer los datos de tus usuarios o modificarlos.

Según la documentación oficial de seguridad de Lovable (https://docs.lovable.dev/features/security), la plataforma trae varias ayudas:

• Si pegás una API key en el chat, Lovable la detecta y te guía para guardarla en Secrets y usarla desde código del lado del servidor, en vez de dejarla escrita en el frontend.
• Un escaneo rápido (Quick scan) que corre solo cada vez que publicás: revisa las reglas de acceso de la base de datos (por ejemplo tablas sin RLS o reglas que dejan pasar a todos) y las dependencias npm con vulnerabilidades conocidas.
• Un escaneo profundo (Deep scan) que podés correr cuando quieras desde la vista Security del proyecto y que revisa el código de la app.

Pero la misma documentación aclara que estas herramientas no garantizan una seguridad completa y que la responsabilidad de que la app sea segura es tuya. Además, se pueden ignorar los avisos y publicar igual, y una clave que pegaste directo en el código o en una variable VITE_ sigue siendo pública. Por eso conviene revisar también la app ya publicada, tal como la ve un visitante.

Cuando ponés una API key en una variable de entorno del frontend, termina dentro de los archivos JavaScript que sirve tu sitio. Las variables que empiezan con VITE_ o NEXT_PUBLIC_ se incluyen en el código público a propósito: son para cosas que pueden verse.

Claves que nunca tienen que llegar al navegador:

• La clave secreta de Supabase (sb_secret_…) o la clave legacy service_role: saltean todas las reglas de RLS y dan acceso total a tus datos.
• Claves de OpenAI, Anthropic u otros proveedores de IA (sk-…).
• Claves secretas de Stripe (sk_live_… / rk_live_…). La clave publicable pk_… sí puede estar en el frontend.
• Claves de servicios de email (Resend, SendGrid…), claves de AWS, tokens de GitHub, cadenas de conexión a la base de datos.

La clave publicable de Supabase (sb_publishable_…) o la legacy anon está pensada para ser pública: Supabase la describe como segura para exponer, siempre que RLS esté bien configurado (https://supabase.com/docs/guides/api/api-keys). Supabase también anunció que va a dar de baja las claves anon y service_role para fines de 2026, reemplazadas por las publishable y secret.

Las apps de Lovable suelen hablar con Supabase directo desde el navegador, usando la clave pública. La seguridad a nivel de fila (Row Level Security, RLS) es lo que decide qué filas puede leer o escribir cada visitante. Si una tabla tiene RLS desactivado —o una política que dice “permitir a todos”—, cualquiera que tenga tu clave pública (que está en tu página) puede leer esa tabla.

Tablas típicamente riesgosas: profiles, users, orders, messages, leads, waitlist, y cualquier cosa con emails, teléfonos o pagos.

Si usás el backend integrado de Lovable (Cloud), las políticas están en More → Cloud → Database → RLS policies. Si conectaste tu propio proyecto de Supabase, las ves en su panel. Supabase recomienda tener RLS activado en todas las tablas de los esquemas expuestos (https://supabase.com/docs/guides/database/postgres/row-level-security).

Ojo con un cambio reciente: desde el 30 de octubre de 2026, las tablas nuevas que crees en el esquema public dejan de quedar accesibles automáticamente para la app hasta que les des permisos (GRANT). Las tablas que ya tenés no cambian, así que siguen necesitando RLS. Lo explicamos en detalle (en inglés) acá: https://leakyvibe.com/guides/supabase-october-30-data-api-change

Es menos grave, pero se arregla fácil: tu sitio debería redirigir de http:// a https:// y mandar algunos headers estándar.

• Strict-Transport-Security: obliga a usar HTTPS.
• X-Frame-Options: DENY o una Content-Security-Policy con frame-ancestors: evita que otro sitio meta el tuyo dentro de un iframe para engañar a la gente y que haga clics sin darse cuenta (clickjacking).
• X-Content-Type-Options: nosniff y una Referrer-Policy.

Revisá también que no se puedan descargar archivos como /.env ni los source maps (.map).

1. Abrí tu app publicada, apretá F12 (herramientas de desarrollador), andá a Sources (Chrome) o Debugger (Firefox) y usá “Buscar en todos los archivos” con: service_role, sb_secret_, sk-, sk_live, rk_live, secret, re_ (Resend), SG. (SendGrid). Si aparece una clave secreta real, es una fuga.
2. En Lovable, abrí la vista Security del proyecto, corré el Quick scan y el Deep scan y resolvé los hallazgos críticos antes de seguir.
3. En el panel de Supabase, en el Table Editor, fijate que todas las tablas tengan RLS activado. Después revisá las políticas y buscá las que tengan “true” como condición en tablas con datos personales.
4. Corré el Security Advisor de Supabase (Database → Advisors) y arreglá lo que marque.
5. Para los headers, mirá la pestaña Network del navegador (clic en la primera solicitud → Response Headers) o cualquier herramienta que revise headers.

O pegá tu URL en el escaneo gratis de LeakyVibe de arriba: hace estos chequeos desde afuera, en modo solo lectura, en unos 15 segundos, y te lista los problemas en lenguaje simple.

1. Clave secreta expuesta: sacarla del código no alcanza, porque versiones viejas pueden estar en caché o ya copiadas. Creá una clave nueva en el panel del proveedor, usala solo del lado del servidor (una Edge Function de Supabase u otra función de servidor, guardada como secreto) y después borrá o desactivá la vieja.
2. RLS apagado: activá RLS en todas las tablas y agregá políticas que permitan solo lo necesario; por ejemplo, que cada usuario solo pueda leer y editar las filas donde user_id = auth.uid().
3. Headers: agregalos en la configuración de tu hosting (por ejemplo los headers de vercel.json o netlify.toml) o pedile a tu herramienta que los agregue.

Un prompt que podés pegar en Lovable como punto de partida (Lovable entiende prompts en español):

Revisá la configuración de Supabase de mi app. Activá Row Level Security en todas las tablas. Agregá políticas para que cada usuario solo pueda leer, crear, editar y borrar sus propias filas (user_id = auth.uid()). Las tablas públicas tienen que ser de solo lectura. Asegurate de que ninguna clave service_role o sb_secret_, API key secreta ni clave secreta de Stripe se use en el código del frontend; mové esas llamadas a Supabase Edge Functions usando secrets. Listá cada cambio que hiciste.

Después del arreglo, probá de nuevo: cerrá sesión (o usá una ventana privada) y confirmá que los datos privados ya no cargan.

• Ninguna clave secreta en el JavaScript público (solo claves publishable/anon).
• RLS activado en todas las tablas de Supabase, sin políticas de “permitir a todos” sobre datos personales.
• Toda clave que alguna vez quedó expuesta ya fue rotada.
• Quick scan y Deep scan de Lovable corridos, sin hallazgos críticos pendientes.
• Redirección a HTTPS y headers de seguridad básicos configurados.
• Ningún /.env ni source map público.

Un escaneo pasivo como LeakyVibe es un primer chequeo rápido, no una auditoría de seguridad completa. Si manejás pagos o datos sensibles, considerá también una revisión profesional.

Fuentes oficiales: Lovable, “Security overview” (https://docs.lovable.dev/features/security); Supabase, “API keys” (https://supabase.com/docs/guides/api/api-keys) y “Row Level Security” (https://supabase.com/docs/guides/database/postgres/row-level-security).