FixVibe

// docs / security guides / lovable checklist

Lovable security checklist: 25 items before launch

Lovable is a fast path from idea to a published full-stack app on Supabase and Vite. This checklist targets the risks that come with that stack: RLS that must be enabled and tightened on every table Lovable creates, test keys from integrations, import.meta.env leaking env vars into the Vite bundle, GitHub sync exposing secrets, and missing security headers. 25 items across secrets, database, auth, headers, deployment, and Lovable-specific gotchas.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

Secretos y claves API (5 artículos)

Las integraciones del mercado de Lovable y la compilación de Vite pueden filtrar variables de entorno en el paquete del cliente si no se tiene cuidado.

  1. PRE — Audit import.meta.env references. Vite expone todas las variables con prefijo VITE_ como import.meta.env.VITE_* en el cliente. Nunca utilices VITE_SUPABASE_SERVICE_KEY o VITE_STRIPE_SECRET. En su lugar, enrútelo a través de un punto final exclusivo del servidor.
  2. Las integraciones de PRE — Replace Lovable marketplace test keys with live restricted keys. Lovable Stripe / Reenviar / etc. a veces se envían con claves sk_test_* o pk_test_*. Antes de publicarlas, cámbielas por claves restringidas activas que limiten los daños en caso de verse comprometidas.
  3. PRE — Check the .env file is not committed. Lovable crea un scaffolding en un archivo .env con claves de integración. Ejecute git ls-files .env. Si se realiza un seguimiento, elimínelo inmediatamente: git rm --cached .env y agréguelo a .gitignore.
  4. PRE — Verify GitHub sync doesn't expose service keys. Si Lovable se sincroniza con GitHub, confirme el flujo de trabajo de acciones GitHub o que la configuración de Vercel no repita los secretos en los registros de compilación. Verifique sus Acciones → Ejecuciones de flujo de trabajo → haga clic en una ejecución → vea si se imprime algún secreto.
  5. La compilación Vite de POST — Run Secrets in JavaScript Bundles on the deployed app. Lovable puede filtrar claves en import.meta.env. Un escaneo pasivo los encontrará.

Control de acceso a la base de datos (5 artículos)

Every table Lovable creates needs RLS enabled and tightened before production.

  1. PRE — Enable RLS on every public table. In Supabase Studio, Tables → for each public.* table → the RLS toggle must be ON, with policies for each command.
  2. PRE — Write explicit policies per table and role. Mínimo: SELECT permite al usuario leer solo filas donde user_id = auth.uid(). Lovable a veces genera tablas sin políticas; debes agregarlos.
  3. PRE — Check Lovable's generated policies, not just the toggle. A policy such as USING (true) keeps RLS "on" while letting every caller through. Scope each policy to auth.uid(). (FORCE ROW LEVEL SECURITY only affects the table owner; it does not fix an open policy.)
  4. DEPLOY — Re-verify RLS is enforced after deploy. Abra Supabase Studio después de la implementación. El interruptor RLS de cada tabla debe ser ON. De lo contrario, su migración no aplicó.
  5. POST — Run a FixVibe scan on the deployed app. Check the Supabase Row-Level Security result: it shows any table an anonymous visitor can read with your public key.

Autenticación y sesiones (4 artículos)

La autenticación de Lovable es Supabase Auth. El riesgo está en cómo Lovable lo conecta.

  1. PRE — Ensure all API routes use getUser(), not getSession(). getSession() lee una cookie no verificada; getUser() valida con Supabase. Busque getSession() en los controladores API y reemplácelo.
  2. PRE — Check Lovable's generated auth handlers for token expiry. Los tokens Magic-link necesitan una caducidad impuesta por el servidor. El valor predeterminado es 1 hora; no lo anule a menos que sea esencial.
  3. PRE — Audit the sign-in redirect guard. El parámetro de consulta next debe comenzar con /, nunca //. Si falta, agregue el protector manualmente.
  4. POST — Test logout destroys the session. Iniciar sesión, cerrar sesión, inspeccionar las cookies (DevTools → Aplicación → Cookies). La cookie de sesión debe borrarse.

HTTP encabezados y CSP (3 elementos)

El andamio Vite de Lovable no agrega CSP de forma predeterminada. Los hosts estáticos requieren una configuración de encabezado explícita.

  1. PRE — Add security headers via your host's config. Vercel: vercel.json headers matriz. Netlify: archivo _headers. Incluya CSP, HSTS, X-Frame-Options, X-Content-Type-Options.
  2. PRE — CSP must not have 'unsafe-inline' in script-src. Utilice nonces o hashes. La compilación Vite de Lovable funcionará con CSP estricto.
  3. POST — Run HTTP Security Headers on the deployed URL. La verificación informa que faltan encabezados y proporciona orientación para solucionar problemas específicos de la plataforma.

Higiene del despliegue (5 artículos)

Lovable hosts published apps itself (Lovable docs). If you export the code and deploy it to Vercel, Netlify or Cloudflare Pages instead, each host handles headers and env vars differently.

  1. DEPLOY — Scope env vars to Production only. Vercel: Configuración → Variables de entorno → alcance cada uno a Producción. Nunca comparta claves de prueba Stripe con Vista previa.
  2. DEPLOY — Verify build logs don't echo secrets. Verifique los registros de compilación de su proveedor de implementación. Si se imprime algún secreto, está comprometido.
  3. DEPLOY — Add security headers to vercel.json or _headers. Para Vercel, utilice headers config. Para Netlify / Cloudflare, use el archivo _headers en el directorio público.
  4. POST — Test a Vercel Preview link in a private browser window. Asegúrese de que CSP nonce esté actualizado en cada solicitud y que los encabezados estén presentes.
  5. POST — Rotate any test key that ever shipped to production. Incluso si es una clave sk_test_*, gírala después de haberla visto en producción.

Lovable errores específicos (3 elementos)

Patrones exclusivos del andamio y el flujo de implementación de Lovable:

  1. import.meta.env is Vite-specific and all-or-nothing. Vite expone VITE_* vars en el paquete del cliente por diseño. No existe un concepto de entorno de servidor exclusivo en Vite sin un límite API separado. El valor predeterminado de Lovable es el de muchos clientes; debe agregar rutas API para operaciones confidenciales.
  2. GitHub sync can auto-commit without review. Si Lovable sincroniza nuevamente los cambios a GitHub, confirme que el flujo de trabajo no se esté impulsando automáticamente sin su aprobación. De lo contrario, una actualización maliciosa podría llegar a main.
  3. Las páginas Static-host headers are a different beast than middleware. Vercel, Netlify y Cloudflare manejan los encabezados de manera diferente. Si cambia de host, vuelva a verificar que se haya aplicado la configuración de su encabezado; es posible que la plataforma no le dé un error si un encabezado no es compatible.

Próximos pasos

Revise general vibe coding security checklist para ver 51 elementos de herramientas cruzadas. Luego consulte step-by-step hardening para conocer patrones más profundos en CSP, RLS y auth.

// escanea tu app

Deja de leer. Empieza a encontrar las brechas en la tuya.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Tier gratis — 3 escaneos / mes, sin tarjeta.
  • Escaneos pasivos contra cualquier URL — sin verificación de dominio.
  • Afinado para Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Lovable security checklist: 25 items before launch · FixVibe