// guía de seguridad
Seguridad para apps hechas con Lovable
Lovable genera apps React + Vite + Supabase listas en minutos. Esa velocidad tiene un precio: la mayoría de los proyectos llegan a producción con configuraciones de seguridad por default que asumen que vos vas a hacer la última milla. Estos son los patrones que vemos cuando auditamos apps Lovable.
// contexto del stack
Contexto de Lovable
Lovable usa Vite como bundler. En Vite, solo las variables con prefijo `VITE_` se exponen al cliente. El resto queda server-side. Esa convención es la principal protección contra leak de claves, pero solo funciona si la respetás. El riesgo no es teórico: la CVE-2025-48757 (CVSS 9.3) documenta RLS insuficiente en apps Lovable que permitía lectura y escritura no autenticada vía la anon key —el proveedor la marcó como DISPUTED, pero el patrón de configuración por default que la origina es real.
// hallazgos frecuentes
Vulnerabilidades más comunes en Lovable
01 Claves de servicios externos con prefijo VITE_
El patrón más común: una clave de Stripe, OpenAI, Resend o Anthropic queda con prefijo VITE_ y termina en el bundle público. Cualquier visitante la lee abriendo DevTools.
→ cómo arreglarlo
Si la clave es secreta (sk_live_, sk-proj-, etc.), NO le pongas el prefijo VITE_. Movela a una variable sin prefijo y usala solo desde endpoints backend (Edge Functions de Supabase, API routes en otro hosting).
02 Supabase con tablas sin RLS
Lovable typically usa Supabase como backend. El schema generado por el asistente raramente incluye `ENABLE ROW LEVEL SECURITY` ni políticas. La anon key está en el bundle, así que sin RLS cualquiera puede leer la base.
→ cómo arreglarlo
En el SQL editor de Supabase, ejecutá `ALTER TABLE nombre_tabla ENABLE ROW LEVEL SECURITY` para cada tabla. Luego escribí políticas tipo `auth.uid() = user_id`. Detalles en nuestro post sobre Supabase RLS.
03 Headers de seguridad ausentes en Cloudflare/Vercel deploy
Cuando publicás un proyecto Lovable a Cloudflare Pages o Vercel, los headers de seguridad (CSP, HSTS, X-Frame-Options) no se configuran automáticamente. Tu app queda vulnerable a XSS, clickjacking y downgrade attacks.
→ cómo arreglarlo
Creá `public/_headers` (Cloudflare) o `vercel.json` con la configuración de headers. Plantilla completa en nuestro post de security headers.
04 console.log y source maps en producción
Vite por default emite sourcemaps y deja `console.log` en el bundle de producción. Los logs pueden contener tokens; los sourcemaps reconstruyen tu código original.
→ cómo arreglarlo
En `vite.config.ts`, configurá `build: { sourcemap: false }` y `esbuild: { drop: ["console", "debugger"] }` para builds de producción.
05 Validación solo en cliente
Los forms generados por Lovable suelen tener atributos HTML5 (`required`, `pattern`) pero rara vez validan en el backend. Cualquier curl al endpoint evita la validación.
→ cómo arreglarlo
Si tu app tiene endpoints API (Supabase Edge Functions, API routes), validá inputs con Zod o similar antes de procesar. Cliente: UX; servidor: seguridad.
// checklist pre-launch
Checklist pre-launch para Lovable
- Buscar `sk_live_`, `sk-proj-`, `service_role` y otras claves en el bundle final con grep
- Verificar que cada variable con prefijo VITE_ es realmente pública (puede estar en el código del frontend sin riesgo)
- Habilitar RLS en todas las tablas Supabase y agregar políticas explícitas
- Probar consulta a Supabase desde la consola sin estar logueado
- Configurar headers CSP, HSTS preload, X-Frame-Options en tu hosting
- Verificar que /.env y /.git/HEAD retornan 404
- Configurar Vite para no emitir sourcemaps en producción y stripear console.log
- Validar inputs servidor con Zod en Edge Functions / API routes
- Auditar con VibeAuditt antes de hacer público
// lectura relacionada
Posts relacionados
// escaneá ahora
Audita tu app Lovable gratis
VibeAuditt detecta automáticamente los errores de este checklist en menos de un minuto. Sin tarjeta, sin instalación.