¿Son seguras las apps de vibe coding? 8 fallos que revisar

¿Son seguras las apps hechas con vibe coding?

No por defecto: todos los grandes estudios citados aquí encontraron fallos de seguridad graves en una gran parte de las apps que examinaron ^[3][4][5]. Las apps suelen funcionar. El problema es lo que dejan hacer a desconocidos.

Una auditoría de 2026 reunió 9.041 apps de código abierto creadas con Claude Code y Lovable y examinó 200 que estaban desplegadas públicamente. Encontró 1.186 vulnerabilidades, y 182 de las 200 apps (91,0 %) tenían al menos una ^[4]. De esos fallos, el 65,77 % se calificó como crítico o alto, incluido un 18,47 % crítico ^[4].

Los autores también comprobaron si mejores prompts y configuraciones de agentes solucionan el problema. Lo redujeron, pero no lo eliminaron, y la misma tarea ejecutada tres veces podía dar un resultado seguro una vez y uno inseguro la siguiente ^[4]. Es decir, un resultado limpio en una versión dice poco de la siguiente.

Para lo básico del método, consulte la guía de Pouyam Vibe Coding Explained: What It Is, How It Works and the Real Risks. Para un primer proyecto, Vibe Coding for Beginners: How to Start Safely in 2026 ofrece un plan de inicio. Esta página baja un nivel más: los fallos concretos y cómo probar cada uno.

¿Qué encuentran los estudios de seguridad en las apps de vibe coding?

Cuatro fuentes independientes señalan el mismo punto débil: datos que la persona equivocada puede leer o cambiar ^[1][3][4][5].

• Auditoría de 200 apps desplegadas (2026): el control de acceso roto fue la mayor categoría, con 339 de 1.186 fallos (28,58 %), y afectó al 64,00 % de las apps. La inyección afectó al 54,00 % y los fallos de autenticación al 51,50 % ^[4].
• Estudio de ACM CCS 2026: en 8.641 repositorios de Lovable con historial completo, el 11,2 % de las reglas de lectura estaba abierto a visitantes sin sesión y el 61,2 % de los repositorios tenía al menos una regla así. Una prueba de reproducción confirmó la exposición en 353 de 400 repositorios de muestra ^[5].
• Escape (octubre de 2025): un análisis pasivo de más de 5.600 apps públicas creadas en plataformas como Lovable, Base44 y Create.xyz halló más de 2.000 vulnerabilidades, más de 400 secretos expuestos y 175 casos de datos personales, entre ellos historiales médicos, IBAN (identificadores de cuenta bancaria), teléfonos y correos ^[3].
• CVE-2025-48757 (2025): un análisis terminado el 21 de marzo de 2025 halló 303 endpoints de base de datos en 170 de 1.645 proyectos de Lovable, cerca del 10,3 %, con reglas de fila inadecuadas ^[1].

Escape subraya que su análisis evitó cualquier acción destructiva, por lo que sus cifras son un mínimo; una prueba más profunda hallaría más ^[3]. La misma cautela vale para todas las cifras: estos estudios cuentan lo que podían ver desde fuera.

¿Por qué las herramientas de IA crean apps inseguras?

Porque las herramientas buscan una app que funcione, y las reglas de seguridad dependen de detalles del negocio que el prompt rara vez indica ^[4][11].

El código que funciona es fácil de comprobar: la página carga, el botón responde. Quién puede ver cada registro es una decisión de negocio, y si nadie la escribe, la herramienta tiene que adivinar. La auditoría de 2026 atribuye los fallos a ocho patrones recurrentes, agrupados en tres límites de los agentes de IA: memoria, objetivos y conocimiento ^[4].

Las pruebas amplias de modelos de IA muestran la misma brecha. El GenAI Code Security Report 2026 de Veracode halló que, en sus pruebas, cerca del 44 % de las tareas de generación de código introdujo una vulnerabilidad de seguridad ^[11]. Un benchmark citado por AWS halló que la mejor de 12 configuraciones de agentes resolvió bien el 57 % de las tareas, pero solo el 11,8 % de forma correcta y segura a la vez ^[10].

Muchas apps de vibe coding, además, trasladan la seguridad a la base de datos. El navegador habla directamente con una base de datos alojada, de modo que sus reglas son lo único entre un visitante y cada fila ^[1][6]. Si faltan o son demasiado amplias, cualquiera que conozca la dirección puede pedirlo todo.

¿Qué 8 fallos de seguridad debo revisar primero?

Empiece por los fallos que los estudios encuentran con más frecuencia, ordenados por el daño que pueden causar ^[1][3][4][5].

1. Reglas de base de datos abiertas: tablas sin row level security o con reglas que dejan a cualquier visitante leer todas las filas. Fue el origen de CVE-2025-48757 y de los hallazgos de ACM ^[1][5].
2. Control de acceso roto: un usuario con sesión abre el registro de otro cambiando un ID en la dirección o en la petición. Fue la mayor categoría de la auditoría de 2026 ^[4].
3. Claves secretas en el navegador: una clave secret o service_role de Supabase, una clave de pagos o de un proveedor de IA en el código del frontend. Escape halló más de 400 secretos expuestos ^[3][6].
4. Verificación de sesión ausente o débil: páginas privadas o rutas de API que responden sin sesión. Los fallos de autenticación afectaron al 51,50 % de las apps auditadas ^[4].
5. Inyección: datos del usuario que llegan sin control a consultas o al HTML, hallada en el 54,00 % de las apps auditadas ^[4].
6. Tablas con escritura abierta: reglas que permiten a visitantes insertar o cambiar datos, no solo leerlos. En el caso del CVE, una petición sin token de sesión insertó un registro marcado como "pagado" y se saltó el pago ^[1].
7. Respuestas que filtran datos: API que devuelven registros completos, correos o tokens cuando la página solo necesita un nombre. Escape contó 175 casos de datos personales expuestos ^[3].
8. Acceso arriesgado del agente: un agente de código con credenciales de producción puede causar daños reales; en julio de 2025 un agente borró una base de datos en uso durante una congelación del código ^[10].

Los fallos 1 a 4 cubren la mayor parte de lo que explotan los atacantes externos, así que pruébelos antes que nada.

¿Cómo pruebo mi app de vibe coding contra estos fallos?

Use la app como lo haría un atacante: como desconocido, como segundo usuario y leyendo lo que recibe el navegador ^[1][4][5]. Ningún paso requiere herramientas especiales.

1. Cree dos cuentas de prueba. Cree un registro con la cuenta A, copie su dirección o ID, entre como la cuenta B e intente abrirlo, editarlo y borrarlo. Si funciona, el control de acceso está roto ^[4].
2. Repita sin sesión. Abra las mismas direcciones en una ventana privada sin sesión. En el caso del CVE, quitar la cabecera de sesión bastó para saltarse todas las comprobaciones ^[1].
3. Observe la pestaña de red. En las herramientas de desarrollo del navegador, revise cada petición de la página y lo que devuelve. Las respuestas deben contener solo lo que esa pantalla necesita, nunca correos o tokens de otros usuarios ^[3].
4. Busque claves en el código de la página. Busque cadenas que empiecen por sb_secret_, la etiqueta service_role o claves de proveedores como pagos o IA. Una clave publishable es normal; una clave secret es una emergencia ^[6].
5. Revise las reglas de cada tabla. En el panel de la base de datos, confirme que row level security está activada en cada tabla y lea cada regla en términos sencillos: quién puede leer y quién puede escribir ^[7].
6. Pruebe entradas extrañas. Pegue textos muy largos, comillas y etiquetas HTML en cada formulario y vea si la app falla o las muestra como código ^[4].

Pruebe solo apps que sean suyas o que tenga permiso para probar. No sondee apps ajenas sin permiso por escrito.

¿Cómo corrijo reglas abiertas de Supabase y claves filtradas?

Active row level security en cada tabla, escriba reglas estrictas, mantenga las claves secretas en el servidor y sustituya cualquier clave filtrada ^[6][7][8].

• Active row level security en todas partes. La guía de Supabase indica activarla en cada tabla de un esquema expuesto ^[7]. Una vez activa, la clave pública no llega a nada hasta que añada reglas ^[7].
• Quite los permisos por defecto. En proyectos que aún los conceden por defecto, una nueva tabla pública empieza con todos los privilegios ya concedidos a los roles sin sesión (anon) y con sesión (authenticated), y añadir reglas no los retira ^[7]. Revóquelos y devuelva solo lo que cada rol necesita ^[7].
• Escriba reglas por usuario. Una regla para una tabla privada debe coincidir con el ID del usuario con sesión, no permitir sin más a cualquiera que haya entrado. Evite reglas siempre verdaderas en tablas sensibles ^[2].
• Mantenga las claves secretas en el servidor. La clave publishable de Supabase es segura en el navegador solo porque las reglas de fila la limitan; las claves secret y service_role saltan todas las reglas y deben quedarse en código de servidor o en variables de entorno seguras ^[6].
• Rote las claves filtradas. Si una clave secreta llegó alguna vez al navegador o a un repositorio de código público, cámbiela y desactive la comprometida, como aconseja la guía de claves de Supabase ^[6].

A 15 de noviembre de 2026, la documentación de Supabase indica que retirará las antiguas claves anon y service_role a finales de 2026 en favor de las claves publishable y secret ^[8]. Las nuevas claves secret devuelven un error (HTTP 401) cuando se usan en un navegador, aunque una clave filtrada aún puede usarse desde otras herramientas ^[6][8]. Migrar ahora es un buen momento para revisar cada clave que usa una app.

¿Los escáneres de seguridad integrados lo detectan todo?

No: los escáneres de las plataformas ayudan, pero varios estudios muestran que pasan por alto las reglas más importantes ^[1][2][5].

En 2025, los investigadores detrás de CVE-2025-48757 vieron que el escáner de Lovable solo comprobaba si existía una regla de fila, no si era correcta ^[1]. Su aviso añade que la comprobación de publicación de Lovable señala tablas sin reglas, pero no indica si las reglas son lo bastante estrictas ^[2]. Una regla abierta supera un control así.

El estudio de ACM lo confirma con cifras: una proporción modesta de reglas abiertas, el 6,3 % en seis herramientas, dejó aun así al 56,9 % de los repositorios con al menos una tabla expuesta, porque basta con una regla abierta ^[5]. Los autores publicaron un verificador gratuito que señala esas reglas antes de hacer commit ^[5].

Use los escáneres como primer filtro y haga usted mismo las pruebas con dos cuentas y sin sesión. La tabla siguiente resume las cifras.

¿Es seguro usar apps que otros hicieron con vibe coding?

Tenga cuidado con todo lo que pida datos personales, de salud o de pago, porque los usuarios no ven cómo los protege una app ^[3][4]. Escape halló historiales médicos e IBAN (identificadores de cuenta bancaria) entre los datos expuestos ^[3].

Algunos hábitos sencillos reducen el riesgo. Use una contraseña distinta para cada app nueva, para que una fuga en una no abra las demás; la guía de Pouyam Password Managers Explained: How They Work and Whether They Are Safe explica cómo. Comparta solo los datos que la app necesita y prefiera páginas de pago de proveedores conocidos antes que formularios dentro de la app.

La responsabilidad principal es de quien crea la app. Si publica una app que guarda datos de otras personas, haga las comprobaciones anteriores antes del lanzamiento y tras cada cambio grande, porque una sola función nueva puede reabrir un fallo cerrado ^[4][5].