Seguridad de apps vibe-coded: los datos reales (2026)
Escaneos de miles de apps hechas con Lovable, Bolt y v0 revelan secretos y bases de datos expuestas. Qué dicen los datos de 2026 y cómo revisar la tuya.
Si lanzaste una app con Lovable, Bolt, v0 o Cursor, hay una pregunta incómoda que casi nadie te hizo: ¿quién puede leer tu base de datos ahora mismo? Los datos de 2026 dicen que, en la mayoría de los casos, la respuesta es “cualquiera con tu URL”. Esto es lo que muestran los escaneos a gran escala —sin marketing del miedo— y cómo revisar la tuya.
TL;DR
- En un escaneo de 1.072 apps vibe-coded con Supabase, el 98% tenía al menos un fallo de seguridad y el 16% uno crítico (Symbiotic Security, 2026).
- Otro estudio de 5.600 apps encontró 2.000+ vulnerabilidades, 400+ secretos expuestos y 175 casos de datos personales —incluidos registros médicos e IBANs— (Escape.tech, 2025).
- El patrón #1: bases de datos de Supabase sin Row Level Security, formalizado en Lovable como CVE-2025-48757 (CVSS 9.3).
- No es tu culpa: la IA optimiza para que funcione, no para que sea seguro. Pero sí es tu responsabilidad revisarlo antes de lanzar.
Qué tan seguras son las apps vibe-coded
Las apps generadas con IA fallan en seguridad por defecto: los escaneos públicos más grandes encuentran al menos un problema en la enorme mayoría de ellas. No es un caso aislado ni una exageración de vendedores de seguridad —es un patrón medido en miles de apps reales, con la misma causa raíz repetida una y otra vez: configuraciones que el modelo nunca aplicó porque nadie se las pidió.
“Vibe-coded” significa describir lo que querés y dejar que la IA lo construya. El problema es que la seguridad no es algo que se “vea” en la demo: la app funciona, se ve bien y pasa los tests, mientras la base de datos queda abierta por detrás.
Qué encontraron los escaneos a gran escala
Tres fuentes independientes midieron esto en 2025–2026, todas en modo pasivo (sin explotar nada, sin tocar datos) y publicando solo resultados agregados:
| Fuente | Muestra | Hallazgo principal |
|---|---|---|
| Symbiotic Security (2026) | 1.072 apps con Supabase | 98% con ≥1 fallo · 16% críticas |
| Escape.tech (2025) | 5.600 apps | 2.000+ vulns · 400+ secretos · 175 PII |
| CVE-2025-48757 (NVD) | — | RLS insuficiente en Lovable, CVSS 9.3 |
Ambos estudios aclaran que sus números son un piso, no un techo: el modo pasivo subestima el problema porque no intenta explotar nada. Y los dos coinciden en el culpable principal.
Qué se filtra exactamente
Lo que se expone cae casi siempre en tres categorías concretas, todas detectables desde el navegador sin herramientas especiales:
- Secretos en el JavaScript público. Claves de Stripe, OpenAI, Google Maps o el
service_rolede Supabase quedan dentro del bundle que tu navegador descarga. Cualquiera abre DevTools y las copia. - Bases de datos sin Row Level Security. Con la anon key de Supabase (que es pública por diseño) y RLS desactivado, un visitante puede leer —o escribir— tablas enteras. Es el corazón de CVE-2025-48757.
- Datos personales. Emails, teléfonos, direcciones, estados de pago. Escape.tech reportó incluso registros médicos e IBANs entre los 175 casos de PII que halló.
Por qué pasa (y por qué no es tu culpa)
Cuando le pedís a un modelo “hacé un dashboard con Supabase”, prioriza que funcione. RLS, headers HTTP, CORS restrictivo y validación en servidor son detalles que no salen al output salvo que los pidas explícitamente —el happy path domina. Los flujos de vibe-coding tampoco tienen un paso de seguridad: idea → app → deploy, sin compuerta en el medio.
La buena noticia: estos errores son configuración faltante, no bugs profundos. Se arreglan rápido una vez que sabés que están.
Cómo revisar tu propia app (gratis, en minutos)
No necesitás ser experto. Tres chequeos manuales cubren la mayor parte del riesgo:
- Secretos: abrí tu sitio, F12 → pestaña Sources, buscá
sk_,service_role,apiKey. Si aparece una clave secreta, está expuesta. - Supabase RLS: tomá tu URL de Supabase y la anon key del bundle y pedí
/(rest/v1/)<tabla>?limit=1sin sesión. Si devuelve filas reales, RLS está abierto. - Archivos filtrados: probá
tu-sitio.com/.git/HEADytu-sitio.com/.env. Si responden con contenido, no deberían.
Si preferís que lo haga una herramienta, VibeAuditt corre 12 chequeos pasivos sobre tu URL en unos 30 segundos —sin tocar tu base de datos, sin payloads— y te dice qué arreglar. Es reconocimiento pasivo, no un pentest. Para profundizar por stack: seguridad en Lovable y seguridad en Supabase.
Qué NO te dicen estos estudios
Acá va la parte honesta que falta en casi todos los artículos sobre el tema:
- “1 de cada 5 apps es vulnerable” es engañoso. La cifra de Wiz se refiere a organizaciones que adoptan estas plataformas, no al porcentaje de apps vulnerables, y no publica tamaño de muestra. No la uses como tasa de prevalencia.
- Los tres estudios son de empresas de seguridad que venden un producto. Sus números son útiles y consistentes, pero son blogs de vendor, no investigación académica revisada. El ancla más neutral es el registro NVD del CVE.
- El CVE-2025-48757 está marcado como “disputado” por el proveedor (argumenta que cada cliente es dueño de los datos de su app). El descubrimiento se atribuye al investigador Matan Getz. Sigue siendo CVSS 9.3.
- Desconfiá de cifras redondas sin fuente como “89% sin RLS” o “67% críticas”: circulan mucho y no tienen metodología detrás.
Que algo sea un commodity de marketing del miedo no lo hace falso —pero sí obliga a separar el dato del titular. El problema es real; la mitad de las cifras que verás, no tanto.
Conclusión
La seguridad de las apps vibe-coded no es un pánico inventado ni una garantía: es un riesgo medible, con una causa raíz repetida (RLS faltante + secretos en el cliente) y un arreglo accesible. Si lanzaste algo con IA, dedicá cinco minutos a los tres chequeos de arriba —o dejá que un escáner pasivo te los haga— antes de que lo haga un desconocido con curiosidad.
// preguntas frecuentes
Preguntas frecuentes
¿Es segura mi app hecha con Lovable o Bolt?
No por defecto. En un escaneo de 1.072 apps con Supabase, Symbiotic Security halló que el 98% tenía al menos un fallo y el 16% uno crítico. Lo más común: claves expuestas en el JavaScript y bases de datos sin Row Level Security. Conviene revisarla antes de lanzar.
¿Qué datos se filtran en las apps vibe-coded?
Tres clases: secretos (claves de Stripe, OpenAI o Supabase en el bundle JS público), bases de datos sin RLS accesibles con la anon key, y datos personales. Escape.tech reportó 400+ secretos y 175 casos de PII —incluidos registros médicos e IBANs— en 5.600 apps.
¿Por qué la IA genera código inseguro?
Los modelos optimizan para que el código funcione, no para que sea seguro. Patrones como RLS, CSP o validación en servidor no aparecen salvo que los pidas explícitamente. No es falta de capacidad del modelo, sino de prioridades: el happy path domina el output.
¿Cómo reviso si mi app filtra datos?
Abrí tu sitio con DevTools (F12) y buscá claves en el bundle JS; probá tu URL de Supabase con la anon key sin sesión; mirá si /.git o /.env responden. O usá un escáner pasivo que corra los chequeos por vos en segundos, sin tocar tu base de datos.
¿Es legal escanear la seguridad de una app web?
Hacer peticiones GET pasivas a páginas públicas —lo que hace cualquier navegador— no suele ser delito de acceso no autorizado en EE.UU. Pero auditá solo apps tuyas o con autorización del dueño, y nunca publiques secretos ajenos ni nombres de sitios vulnerables.
// escanear ahora
Audita tu SaaS gratis
Recibí un reporte de seguridad en menos de un minuto. Detectamos claves expuestas, RLS deshabilitado, headers de seguridad ausentes y más. Sin tarjeta, sin instalación.
10 auditorías gratis al mes · reportes detallados desde 9 USD