POR QUÉ TODO PROYECTO LOVABLE NECESITA PRUEBA DE SEGURIDAD

El riesgo escondido en el desarrollo con IA

Entiéndeme bien — Lovable es increíble. Se pueden construir aplicaciones enteras en horas que antes tomaban semanas. Pero hay algo de lo que nadie habla: cuando vas a esa velocidad, la seguridad suele quedarse atrás.

Las herramientas de seguridad tradicionales no fueron hechas para código generado por IA. Dejan pasar los patrones y vulnerabilidades que emergen cuando una IA escribe buena parte de tu aplicación. Por eso construimos el Scanner de Seguridad Lovable.

¿Qué hace diferentes a los proyectos Lovable?

Los asistentes de código con IA como Lovable revolucionaron la forma de construir aplicaciones web. Pero también introducen consideraciones de seguridad únicas que los scanners tradicionales no capturan:

• Vulnerabilidades por default: la IA a veces genera patrones de código que funcionan perfecto pero contienen fallos sutiles de seguridad
• Puntos ciegos en integraciones: cuando la IA conecta servicios y APIs distintos, pueden surgir huecos de seguridad entre componentes
• Riesgos de iteración rápida: la velocidad del desarrollo con IA puede hacer que la deuda de seguridad crezca más rápido de lo que una revisión manual puede detectar

Problemas reales que encontramos en proyectos Lovable

Después de escanear muchas apps Lovable, identificamos varios patrones comunes que los desarrolladores deben observar:

Los 6 flujos de vibe coding que más se rompen

“Vibe coding” — entregar una app funcional conversando con una IA y nunca leer la mitad del código generado — tiene una forma predecible. En más de 1.430 escaneos Lovable, los mismos seis flujos responden por la mayoría de los críticos. Si endurecieras solo estos, eliminarías la mayoría de los bugs que impactan producción en apps generadas por IA.

Cada uno de estos flujos produce el mismo síntoma en nuestros reportes: UI limpia, app funcionando y un hallazgo crítico en el endpoint detrás. El scanner recorre los seis automáticamente. Para más contexto sobre por qué estos patrones aparecen en código generado por IA, ver Vibe Coding Security Checks y el baseline RLS del caso de la beauty blogger.

Mala configuración de RLS: la vulnerabilidad #1

Después de escanear 1.430+ aplicaciones Lovable, una vulnerabilidad sobresale por encima de todas: políticas de Row Level Security (RLS) ausentes o mal configuradas. Este problema sigue disparándose en proyectos Lovable nuevos.

Lovable usa Supabase como base de datos. Supabase expone un endpoint público de API que cualquiera puede llamar directamente. Sin políticas de RLS, nada impide a un atacante leer cada fila de tu BD, modificar datos de otros usuarios o borrar registros completamente.

Los cuatro checks de RLS que toda tabla necesita

RLS no es un solo interruptor. Es una política por operación, por tabla. Deja una pasar y la superficie de ataque sigue abierta de par en par. Nuestro scanner corre las cuatro en cada tabla pública que descubre:

El error común: los desarrolladores prueban SELECT, ven que está bloqueado y lanzan. Las escrituras quedan abiertas. Lo vemos en ~30% de las apps que “habilitaron RLS”.

Políticas rotas que parecen correctas

Estas son las políticas de RLS que más señalamos — compilan, la app funciona y la tabla sigue expuesta:

-- MAL: sin WITH CHECK el usuario puede INSERT filas de cualquiera
CREATE POLICY "insert own" ON posts
  FOR INSERT USING (auth.uid() = user_id);

-- MAL: UPDATE solo con USING; el usuario actualiza su propia fila
-- y cambia el user_id al de otra persona al mismo tiempo
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id);

-- MAL: lee las propias + marcadas como públicas, sin filtro
-- de columna — campos sensibles en filas "públicas" se filtran
CREATE POLICY "read public or own" ON posts
  FOR SELECT USING (is_public OR auth.uid() = user_id);

-- MAL: el clásico fix "solo para que funcione"
CREATE POLICY "allow all" ON posts FOR ALL USING (true);

Las versiones corregidas — los patrones que aguantan cuando se prueban:

-- BIEN: INSERT con WITH CHECK ata la nueva fila al que llama
CREATE POLICY "insert own" ON posts
  FOR INSERT WITH CHECK (auth.uid() = user_id);

-- BIEN: UPDATE exige que la fila actual pertenezca al que llama
-- Y que la nueva versión también (impide transferencia de dueño)
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id)
              WITH CHECK (auth.uid() = user_id);

-- BIEN: DELETE con alcance de dueño
CREATE POLICY "delete own" ON posts
  FOR DELETE USING (auth.uid() = user_id);

-- BIEN: SELECT explícito, sin ambigüedad
CREATE POLICY "read own" ON posts
  FOR SELECT USING (auth.uid() = user_id);

Para columnas con PII (email, teléfono, stripe_customer_id), prefiere una view con columnas restringidas en lugar de grants a nivel de columna — es más difícil configurar mal y más fácil de auditar.

Prueba tu RLS en 30 segundos

No necesitas nuestro scanner para un primer repaso. Abre tu app Lovable en producción, agarra la URL de Supabase y la anon key de la pestaña Network y corre:

# Sustituye por tu proyecto + anon key + tabla
SUPA="https://<project>.supabase.co"
KEY="<anon_key>"
TABLE="profiles"

# Probe de lectura — debe venir vacío o 401 sin login
curl "$SUPA/rest/v1/$TABLE?select=*&limit=5" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY"

# Probe de escritura — debe ser 401 o rechazo por política
curl -X POST "$SUPA/rest/v1/$TABLE" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"id":"rls-probe-delete-me"}'

Si vienen filas o la escritura pasa, tienes un crítico. Ejecuta el Supabase RLS Checker gratis para el reporte completo por tabla, o pega la URL en el scanner al inicio de esta página para la auditoría Lovable completa (auth, storage, edge functions y claves, además de RLS).

Cuando RLS no alcanza

RLS frena la anon key. No frena:

• Edge Functions usando la service-role key — estas ignoran RLS por completo. Cualquier error lógico dentro de una función es lectura/escritura completa de la BD.
• JWTs filtrados — si se filtra el JWT de un usuario logueado (XSS, un gist público, una captura de pantalla), RLS sirve alegremente al atacante lo que ese usuario vería.
• Storage — Storage tiene reglas parecidas a RLS por bucket y por objeto. Se configuran por separado y, en apps Lovable, suelen quedar como “public bucket”.
• Vistas y funciones de BD — una función SECURITY DEFINER corre con privilegios del creador, no del que llama. Si recibe un ID provisto por el usuario y confía en él, RLS se vuelve irrelevante.

Nuestro scanner prueba las cuatro. Para entender el modelo de política subyacente, ver la guía de RLS de Supabase y la checklist de seguridad de Supabase.

Cómo funciona el Scanner de Seguridad Lovable

Nuestro scanner fue hecho específicamente para entender la arquitectura de Lovable. Esto es lo que pasa cuando escaneas tu proyecto:

1. Descubrimiento automático: crawleamos tu aplicación para entender estructura, rutas y funcionalidad
2. Pruebas con IA: 13 agentes de IA especializados prueban escenarios de ataque específicos para aplicaciones web
3. Detección de vulnerabilidades: identificamos problemas de seguridad, desde malas configuraciones básicas hasta bypasses complejos de autenticación
4. Reportes accionables: explicaciones claras de los problemas encontrados y pasos específicos para corregir

Más allá del escaneo: cobertura de seguridad completa

El Scanner de Seguridad Lovable no es solo sobre encontrar vulnerabilidades. Es una solución de seguridad completa:

• Pruebas multi-navegador: asegura que tu app funcione con seguridad en distintos navegadores
• Verificación de RLS de Supabase: prueba end-to-end de tus políticas de Row Level Security
• Monitoreo diario: escaneo continuo para detectar problemas nuevos conforme tu app evoluciona
• Prevención de filtración de datos: detecta información sensible que pueda estar expuesta
• Protección de tokens de API: evita la exposición accidental de credenciales sensibles
• Checks de listos para lanzar: validación exhaustiva de seguridad pre-deploy

Lo que están encontrando los desarrolladores

Entre las 5.711 vulnerabilidades encontradas en 1.430+ apps escaneadas, este es el ranking de los problemas más comunes:

1. RLS ausente en SELECT — Crítico. Presente en 85% de los escaneos.
2. RLS ausente en INSERT/UPDATE/DELETE — Crítico. Presente en 51% de los escaneos. Normalmente sale junto con una política de SELECT funcional, por eso pasa desapercibido.
3. Claves de API expuestas — Crítico. Presente en 62% de los escaneos. OpenAI, Anthropic, Stripe y Resend son las cuatro más filtradas.
4. Bypasses de autenticación — Alto. Presente en 45% de los escaneos. Normalmente un route guard solo en el frontend.
5. Validación de entrada ausente — Alto. Presente en 38% de los escaneos.
6. Bucket de Storage público — Alto. Presente en 34% de las apps Lovable que usan Storage.
7. Gates de función de pago solo en el frontend — Alto. Presente en 27% de las apps monetizadas.
8. Service-role key en código cliente — Crítico. Raro (~4%), pero siempre es takeover total.

Empezar es simple

No necesitas ser experto en seguridad para proteger tus proyectos Lovable. Pega la URL de tu app en producción arriba. En minutos recibes un reporte exhaustivo de seguridad con recomendaciones accionables.

Empieza con un trial gratis de 14 días. Sin setup largo. Solo insights de seguridad reales para aplicaciones reales.