Pasé los últimos tres meses auditando aplicaciones que los clientes nos trajeron después de construir sus MVPs en Lovable. El patrón es tan consistente que es casi aburrido: claves de servicio de Supabase expuestas en bundles de cliente, cero políticas de RLS, secretos de OpenAI y Stripe codificados directamente en JavaScript para que cualquiera con DevTools los capture. Cada vez.

Este no es un artículo de crítica hacia Lovable. La plataforma es genuinamente impresionante para prototipos. Pero hay un abismo del tamaño de un cañón entre "demo funcional" y "aplicación lista para producción", y Lovable no te cuenta sobre la mayoría de lo que se encuentra en ese abismo. Un investigador comunitario auditó 50 aplicaciones construidas por IA y encontró los mismos cinco errores de seguridad en casi todas ellas. Otro desarrollador escaneó más de 200 sitios codificados por IA y encontró una puntuación promedio de seguridad de 52 de 100 -- con los peores casos concentrados específicamente en aplicaciones de Lovable + Supabase.

Veamos todas las vulnerabilidades que seguimos encontrando, por qué las propias herramientas de Lovable las pierden, y exactamente cómo arreglar cada una.

Tabla de Contenidos

Vulnerabilidades de Seguridad de Lovable 2026: Claves Expuestas, RLS Faltante, y Lo Que los Auditorios Detectan

La Arquitectura Que Crea el Problema

Para entender por qué las aplicaciones de Lovable se ven desproporcionalmente afectadas, necesitas entender la arquitectura. Lovable usa exclusivamente Supabase como backend. No hay opción de Firebase, sin backend personalizado, sin puerta de escape. Cuando construyes algo en Lovable, genera un frontend de React que se comunica directamente con la API REST de Supabase usando la librería del cliente.

Supabase está diseñado de modo que la clave anon sea segura de exponer públicamente -- es esencialmente un identificador de proyecto. El modelo de seguridad se basa completamente en políticas de Seguridad de Nivel de Fila (RLS) a nivel de PostgreSQL. Piénsalo de esta manera:

Componente ¿Se supone que es público? Qué te protege
URL de Supabase Sí Nada necesario -- es solo una URL
Clave anon Sí Políticas de RLS en cada tabla
Clave service_role Absolutamente no Debe permanecer solo en servidor
Cadena de conexión de base de datos No Nunca exponer a clientes

El problema es que Lovable's AI genera código que a menudo trata todos estos de la misma manera. Pone la clave anon en el frontend (bien), pero luego crea tablas sin habilitar RLS (catastrófico). A veces pone la clave service_role en código de cliente también (fin del juego). Como lo dijo un desarrollador en Reddit: "AI hace lo que le pides. Solo nunca piensa en lo que no le pediste."

Vulnerabilidad 1: Claves de Supabase Expuestas en Código de Cliente

Cada aplicación de Lovable inicializa el cliente de Supabase algo como esto:

// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

El hecho de que la clave anon esté aquí está bien -- es por diseño. El problema viene de dos formas:

La Fuga de la Clave `service_role`

Hemos visto código generado por Lovable donde la clave service_role termina en código del lado del cliente, generalmente porque alguien le pidió a la IA algo como "hazlo funcionar aunque RLS lo esté bloqueando". ¿La solución de la IA? Usar la clave de administrador. La clave service_role omite todas las políticas de RLS completamente. Si está en tu bundle de frontend, cualquiera puede extraerla y tener acceso completo de lectura/escritura a toda tu base de datos.

El Archivo `.env` Comprometido en Git

Los proyectos de Lovable desplegados en GitHub frecuentemente tienen archivos .env comprometidos en el repositorio. Incluso si el repositorio es privado ahora, si alguna vez fue público -- incluso por un minuto -- esas claves están comprometidas. Los bots rastrean GitHub constantemente buscando exactamente este patrón.

Cómo verificar:

# Busca claves service_role en tu código
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .

# Revisa el historial de git para secretos comprometidos accidentalmente
git log --all -p -- '*.env'

Cómo arreglarlo: Elimina la clave service_role de todo el código de cliente inmediatamente. Rota la clave en tu panel de Supabase (Configuración → API). Usa la clave solo en código del servidor -- Funciones de Supabase Edge, una ruta de API de Next.js, o un backend separado.

Vulnerabilidad 2: Políticas de RLS Faltantes o Rotas

Este es el grande. CVE-2025-48757 expuso 303 puntos de conexión vulnerables en más de 170 aplicaciones construidas con Lovable. Según Escape.tech, el 83% de las bases de datos de Supabase expuestas implican malconfiguraciones de RLS.

Así es lo que pasa por defecto cuando Lovable crea una tabla:

-- Lo que Lovable frecuentemente genera
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  full_name TEXT,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- ¿Nota lo que falta? RLS no está habilitado.
-- Esta tabla es completamente legible y escribible por cualquiera con la clave anon.

Sin RLS, tu base de datos de Supabase es esencialmente una API pública. Cualquiera que conozca tu URL de proyecto y clave anon -- ambas en tu código de frontend -- puede hacer esto:

// Consola del navegador de un atacante
const { data } = await supabase.from('user_profiles').select('*')
// Devuelve los datos de CADA usuario

await supabase.from('user_profiles').delete().neq('id', '')
// Borra todo

Tres Formas de Falla de RLS

Modo de Falla Qué Pasa Severidad
RLS no habilitado en absoluto Acceso público completo de lectura/escritura Crítica
RLS habilitado pero sin políticas definidas Nadie puede acceder a nada (la aplicación se rompe) Alta (fuerza a los devs a deshabilitar RLS)
Políticas demasiado permisivas (p. ej., USING (true)) Se ve seguro, en realidad no lo es Alta

La tercera es particularmente insidiosa. Hemos visto a Lovable generar políticas como esta cuando se le pide que "arregle los permisos":

CREATE POLICY "Allow all access" ON user_profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);

Esto es teatro de RLS. Está habilitado, tiene una política, y no hace absolutamente nada.

Lo que se ve como una política apropiada:

-- Habilitar RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Los usuarios solo pueden leer su propio perfil
CREATE POLICY "Users read own profile" ON user_profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Los usuarios solo pueden actualizar su propio perfil
CREATE POLICY "Users update own profile" ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Solo usuarios autenticados pueden insertar, y solo para ellos mismos
CREATE POLICY "Users insert own profile" ON user_profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

Vulnerabilidades de Seguridad de Lovable 2026: Claves Expuestas, RLS Faltante, y Lo Que los Auditorios Detectan - arquitectura

Vulnerabilidad 3: Secretos de API de Terceros Codificados

Este me hace estremecer cada vez. Regularmente encontramos claves de API de OpenAI (sk-...), claves secretas de Stripe (sk_live_...), claves de SendGrid, y otras credenciales codificadas directamente en componentes de React.

// Realmente encontrado en un archivo generado por Lovable
const openai = new OpenAI({
  apiKey: 'sk-proj-abc123...',  // Esto está en tu bundle del navegador
})

Cualquiera que abra DevTools, vaya a la pestaña Fuentes, y busque sk- o sk_live obtiene tus claves. Los atacantes automatizan esto. Hay bots que específicamente rastrean bundles de JavaScript buscando estos patrones.

El impacto financiero es real. Tuvimos un cliente que vino a nosotros después de que una clave de OpenAI expuesta resultó en $4,200 en cargos durante un fin de semana. Las claves secretas de Stripe son peor -- otorgan acceso completo para procesar reembolsos, ver datos de clientes, y modificar suscripciones.

La solución: Mueve todas las llamadas de API de terceros a funciones del lado del servidor. Las Funciones de Supabase Edge funcionan bien para esto:

// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const { prompt } = await req.json()
  
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
    }),
  })
  
  return new Response(JSON.stringify(await response.json()))
})

Vulnerabilidad 4: Encabezados de Seguridad Faltantes

El escaneo de más de 200 sitios encontró que la mayoría de las aplicaciones desplegadas por Lovable se envían con cero encabezados de seguridad. Sin Content-Security-Policy. Sin Strict-Transport-Security. Sin X-Frame-Options. Sin X-Content-Type-Options.

Esto podría parecer menor comparado con una base de datos expuesta, pero los encabezados faltantes permiten:

  • Clickjacking -- tu aplicación puede ser incrustada en un iframe en un sitio malicioso
  • Amplificación de XSS -- sin CSP, los scripts inyectados no tienen restricciones
  • Ataques de olfateo de tipo MIME -- los navegadores pueden interpretar archivos como código ejecutable
  • Ataques de degradación -- sin HSTS, el tráfico puede ser interceptado
Encabezado Propósito Predeterminado de Lovable
Content-Security-Policy Previene XSS, controla carga de recursos Faltante
Strict-Transport-Security Fuerza HTTPS Faltante
X-Frame-Options Previene clickjacking Faltante
X-Content-Type-Options Previene olfateo de MIME Faltante
Referrer-Policy Controla información de referente Faltante
Permissions-Policy Controla características del navegador Faltante

Vulnerabilidad 5: Sin Validación o Sanitización de Entrada

Los formularios generados por Lovable típicamente envían entrada del usuario directamente a Supabase sin ninguna validación. Sin verificaciones de longitud, sin validación de tipo, sin sanitización de HTML o contenido de SQL-adyacente.

Mientras que la capa PostgREST de Supabase previene inyección SQL tradicional, la falta de validación de entrada aún permite:

  • XSS almacenado a través de HTML sin sanitizar en campos de texto
  • Denegación de servicio a través de cargas extremadamente grandes
  • Abuso de lógica empresarial (p. ej., cantidades negativas, precios de $0.00)
  • Corrupción de datos de tipos inesperados

Lo Que el Análisis de Seguridad Incorporado de Lovable Realmente Verifica

Lovable tiene una función de "Análisis de Seguridad" incorporada accesible desde el panel. Crédito donde corresponde -- existe. Pero aquí hay lo que realmente cubre versus lo que no:

Verificación Análisis Incorporado Auditoría de Producción
Errores básicos de sintaxis ✅ ✅
CVEs de dependencias conocidas Parcial ✅
Secretos codificados en fuente ❌ ✅
RLS habilitado en todas las tablas ❌ ✅
Corrección de política de RLS ❌ ✅
Exposición de clave service role ❌ ✅
Encabezados de seguridad ❌ ✅
Cobertura de validación de entrada ❌ ✅
Revisión de configuración de autenticación ❌ ✅
Políticas de bucket de almacenamiento ❌ ✅
Limitación de velocidad ❌ ✅
Banderas de seguridad de cookie ❌ ✅

El análisis incorporado es de nivel superficial en el mejor de los casos. No atrapará las vulnerabilidades que realmente se explotan.

Lo Que una Auditoría de Producción Detecta Que la Plataforma No

Cuando hacemos una auditoría de seguridad de producción para un cliente que ha construido en Lovable, aquí hay lo que típicamente encontramos y arreglamos. Esta es la lista real, de compromisos actuales:

Capa de Base de Datos

  • Tablas con RLS deshabilitado (promedio: 60-70% de tablas)
  • Políticas de RLS usando true como condición
  • Políticas faltantes para operaciones DELETE (los desarrolladores olvidan sobre delete)
  • Sin políticas en tablas de unión/join
  • Buckets de almacenamiento establecidos como públicos sin restricciones de carga
  • Índices faltantes en columnas usadas en condiciones de política de RLS (rendimiento + seguridad)

Capa de Autenticación

  • Secretos JWT débiles (Los predeterminados de Supabase están bien, pero a veces la gente los cambia)
  • Requisitos de confirmación de correo electrónico faltantes
  • Sin limitación de velocidad en puntos de conexión de auth
  • Flujos de restablecimiento de contraseña sin expiración adecuada de token
  • Malconfiguraciones de URL de redirección de OAuth

Capa de Código de Cliente

  • Claves service_role en bundles de frontend
  • Claves de API de terceros codificadas en componentes
  • Archivos .env comprometidos en historial de git
  • Registro de depuración que expone datos de usuario en la consola
  • Mensajes de error que revelan información de esquema de base de datos

Capa de Infraestructura

  • Sin encabezados de seguridad whatsoever
  • Cookies sin banderas Secure, HttpOnly, o SameSite
  • Información de versión de servidor expuesta
  • Sin configuración de CORS (acepta solicitudes de cualquier origen)
  • Dependencias con CVEs conocidos que no se han actualizado en meses

Una aplicación típica de Lovable que auditamos necesita 15-25 arreglos antes de estar lista para producción. La mayoría de ellos toman menos de una hora cada una, pero necesitas saber que existen primero.

El Incidente de Moltbook: Un Caso de Estudio Real

En enero de 2026, investigadores de seguridad en Wiz descubrieron que Moltbook -- una red social de IA -- tenía toda su base de datos de Supabase expuesta a través de un cliente mal configurado. La clave anon estaba en el JavaScript de frontend (normal), pero RLS no se configuró en tablas críticas (catastrófico).

¿El resultado? 1.5 millones de claves de API eran accesibles. No solo datos de usuario -- claves de API reales pertenecientes a usuarios que habían conectado sus cuentas de OpenAI, Anthropic, y otros. Acceso completo de lectura y escritura a cada tabla. Un investigador podría examinar toda la base de datos solo usando el cliente de Supabase en una consola del navegador.

La cronología de divulgación fue ajustada -- el mantenedor de Moltbook arregló las tablas críticas dentro de horas de ser contactado. Pero la ventana de daño fue desconocida. ¿Cuánto tiempo había estado expuesta la base de datos antes de que alguien la verificara? Nadie lo sabe.

Este es el patrón de Lovable + Supabase jugando a escala. La plataforma genera código funcional. Solo que no genera código seguro.

Cómo Arreglar una Aplicación de Lovable Antes de Ir a Producción

Aquí está la lista de verificación que usamos. Puedes hacer la mayoría de esto tú mismo si te sientes cómodo con SQL y el panel de Supabase:

Paso 1: Audita Cada Tabla para RLS

-- Ejecuta esto en el Editor SQL de Supabase para encontrar tablas sin RLS
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = 'public';

Cualquier tabla donde rowsecurity sea false necesita atención inmediata.

Paso 2: Busca en Tu Código Secretos

# Busca patrones de secreto comunes
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .

Paso 3: Escribe Políticas de RLS Apropiadas

Para cada tabla, escribe políticas explícitas para SELECT, INSERT, UPDATE, y DELETE. Siempre usa verificaciones auth.uid():

-- Plantilla para una tabla propiedad del usuario
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "select_own" ON your_table FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "insert_own" ON your_table FOR INSERT
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "update_own" ON your_table FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "delete_own" ON your_table FOR DELETE
  USING (auth.uid() = user_id);

Paso 4: Mueve Llamadas de API al Lado del Servidor

Cualquier llamada de API de terceros que requiera una clave secreta necesita ejecutarse en una Función de Supabase Edge o un backend separado. Esto es innegociable.

Paso 5: Agrega Encabezados de Seguridad

Si estás desplegando en Netlify, Vercel, o Cloudflare, agrega encabezados a través de su configuración. Para Netlify, crea un archivo _headers. Para una aplicación de Next.js, agrégalos en next.config.js.

Paso 6: Considera una Migración de Framework

Para cualquier cosa más allá de un MVP, frecuentemente recomendamos migrar código de React generado por Lovable a un proyecto adecuado de Next.js o Astro. Esto te da rutas de API del lado del servidor, manejo adecuado de variables de entorno, middleware para verificaciones de auth, y un pipeline de construcción real. Es más trabajo inicialmente, pero la postura de seguridad es noche y día.

Herramientas para Escaneo Automatizado

Varias herramientas han surgido específicamente para auditar aplicaciones generadas por IA:

Herramienta Qué Verifica Costo
Ship Safe (npx ship-safe audit .) RLS, exposición de service_role, buckets de almacenamiento, CVEs de dependencias Gratis, código abierto
Vibe App Scanner (vibeappscanner.com) Escaneo completo de seguridad para aplicaciones construidas por IA Escaneo gratuito de inicio
Snyk Vulnerabilidades de dependencias, escaneo de código Nivel gratuito disponible
Panel de Supabase → Auth → Policies Editor de política de RLS visual Incluido con Supabase

Ship Safe es con el que comenzaría. Se ejecuta localmente, nada sale de tu máquina, y está específicamente construido para las malconfiguraciones de Supabase que crean las herramientas de IA:

npx ship-safe audit .

Marcará RLS deshabilitado, claves service_role en código de cliente, buckets de almacenamiento abiertos, configuración de auth débil, secretos codificados, y CVEs de dependencias.

Preguntas Frecuentes

¿Es seguro exponer la clave anon de Supabase en código de frontend? Sí -- pero solo si tienes políticas de RLS apropiadas en cada tabla. La clave anon está diseñada para ser pública. Es como un identificador de proyecto. La seguridad viene de las políticas de RLS que controlan a qué puede acceder realmente esa clave. Sin RLS, la clave anon otorga acceso completo a la base de datos a cualquiera.

¿Lovable habilita RLS por defecto al crear tablas? No. A partir de principios de 2026, Lovable crea tablas de Supabase sin habilitar RLS por defecto. Esta es la brecha de seguridad más grande de la plataforma. Necesitas habilitar manualmente RLS y escribir políticas para cada tabla después de que Lovable las genere. CVE-2025-48757 fue un resultado directo de este comportamiento predeterminado.

¿Cómo verifico si mi aplicación de Lovable tiene secretos expuestos? Abre tu aplicación desplegada en un navegador, abre DevTools (F12), ve a la pestaña Fuentes, y busca en todos los archivos sk-, sk_live, service_role, y cualquier prefijo de clave de API para servicios que uses. También ejecuta npx ship-safe audit . localmente en tu código para detección automatizada.

¿Puede el análisis de seguridad incorporado de Lovable detectar problemas de RLS? El análisis de seguridad incorporado no verifica malconfiguraciones de RLS, políticas faltantes, o claves service expuestas. Cubre problemas de nivel de código básico pero pierde las vulnerabilidades de base de datos e infraestructura que representan el riesgo más alto. Necesitas herramientas externas para una evaluación de seguridad real.

¿Qué pasó con CVE-2025-48757? CVE-2025-48757 fue una divulgación de vulnerabilidad que identificó 303 puntos de conexión vulnerables en más de 170 aplicaciones construidas con Lovable. La causa raíz era Lovable creando tablas de Supabase sin habilitar RLS, dejando bases de datos completas accesibles a cualquiera con la clave anon disponible públicamente. Destacó la naturaleza sistémica del problema.

¿Debería migrar de Lovable para aplicaciones de producción? No necesariamente. Lovable es excelente para prototipado rápido y construcción de MVPs. Pero el código generado necesita endurecimiento de seguridad significativo antes del uso en producción. Muchos equipos usan Lovable para construir la versión inicial, luego migran a un framework adecuado con renderizado del lado del servidor, gestión de secretos apropiada, y middleware de seguridad. Ese es un enfoque razonable.

¿Cuánto tiempo toma asegurar una aplicación de Lovable para producción? Para una aplicación típica con 10-20 tablas, espera 2-5 días de trabajo enfocado para auditar todas las políticas de RLS, mover secretos al lado del servidor, agregar encabezados de seguridad, validar entradas, y probar todo. Las aplicaciones más complejas con buckets de almacenamiento, suscripciones en tiempo real, y múltiples roles de usuario pueden tomar más tiempo. No es insuperable, pero tampoco es una tarea de una hora.

¿Otros constructores de aplicaciones de IA como Bolt o Cursor son más seguros que Lovable? El escaneo de más de 200 sitios encontró que las vulnerabilidades de seguridad estaban concentradas específicamente en aplicaciones de Lovable + Supabase. Las aplicaciones basadas en Bolt, Replit, y Cursor/Cline no mostraron el mismo patrón de malconfiguraciones de RLS. Eso no significa que sean perfectamente seguras -- todo el código generado por IA necesita revisión -- pero la integración específica de Lovable-Supabase crea una clase única de vulnerabilidades de exposición de base de datos que otras herramientas no tienen.