¿Es seguro el vibe coding? Los riesgos reales y qué revisar antes de publicar

El vibe coding es seguro para herramientas personales y prototipos, y puede serlo también para apps reales con usuarios reales, pero solo si añades las comprobaciones que se salta el «descríbelo y mira si funciona». Los problemas peligrosos no se ven en la pantalla: usuarios que pueden abrir los datos de otros, claves secretas en el navegador y formularios públicos sin límites. Esta guía explica los riesgos que de verdad causan problemas, cómo gestionar los secretos, cuánta revisión necesitas y una comprobación de 30 minutos que conviene hacer antes de publicar.

Para la lista técnica completa, consulta nuestra lista de comprobación de seguridad para apps creadas con IA. Esta página es la versión corta y práctica, pensada para personas que no leen código.

Por qué el vibe coding tiene riesgos propios

Cuando haces vibe coding, juzgas la app usándola. Eso detecta botones rotos y diseños feos. No detecta problemas que solo aparecen cuando alguien usa la app de forma distinta a ti: un desconocido, un bot, una persona curiosa que edita una dirección web.

Los modelos de IA escriben código plausible, y la mayor parte está bien. Pero optimizan para lo que pediste («haz que el panel muestre mis proyectos») y pueden no añadir la protección que no pediste («y que no muestre los de nadie más»). La solución no es dejar de hacer vibe coding, sino pedir explícitamente las protecciones y luego probarlas.

¿Qué riesgo tiene tu app? Una escala rápida

Sé honesto sobre en qué fila estás. Muchas apps empiezan en la primera y acaban en la tercera sin que nadie lo decida.

Los riesgos que de verdad causan problemas

1. Los usuarios pueden ver los datos de otros

Este es el problema grave más frecuente en apps creadas con IA. La página muestra a cada usuario solo sus registros, así que parece correcta. Pero el servidor devolverá cualquier registro si alguien cambia el ID en la barra de direcciones o en una petición. Como siempre pruebas como tú mismo, nunca lo ves.

Cómo comprobarlo: crea dos cuentas. Inicia sesión como el usuario A, abre uno de los registros de A y anota la dirección. Inicia sesión como el usuario B en una ventana privada y pega esa dirección. Deberías ver «no encontrado», nunca los datos de A.

Prompt:

Revisa cada endpoint del servidor que lea, modifique o borre datos de usuarios. Cada uno debe confirmar que la persona con sesión iniciada tiene permiso para acceder a ese registro concreto. Enumera los endpoints, indica cómo comprueba cada uno el acceso y corrige los que no lo hagan.

2. Secretos en el lugar equivocado

Un secreto es cualquier cosa que conceda acceso: una clave de API de un servicio de IA o de correo, una contraseña de base de datos, la clave secreta de un proveedor de pagos. Si está en código que se ejecuta en el navegador, cualquiera puede abrir las herramientas de desarrollo y copiarla. Si se sube a un repositorio público, los bots la encuentran en cuestión de horas.

Cómo comprobarlo: pregúntale a la IA.

Enumera cada clave de API, token y contraseña que usa esta app. Para cada una, indica dónde se guarda y si alguna vez se envía al navegador. Mueve al servidor, como secretos del lado del servidor, cualquiera que esté en el código o en el frontend.

3. Formularios y endpoints públicos sin límites

Los formularios de contacto, los registros y las funciones de IA los encuentran los bots. Sin límites, recibes spam, cuentas falsas o una factura elevada por una API de IA a la que se llama miles de veces.

Prompt:

Añade límites de peticiones al registro, al inicio de sesión, al formulario de contacto y a cada endpoint que llame a un servicio de IA. Añade un campo trampa (honeypot) a los formularios públicos. Indícame los límites que has elegido.

4. Confiar en el navegador

Todo lo que decide el navegador puede modificarlo el usuario: precios, descuentos, respuestas de un test, marcas de «es administrador». Las reglas que importan deben aplicarse en el servidor.

Prompt:

Busca cualquier lugar en el que el navegador decida algo que debería decidir el servidor: precios, totales, permisos, roles, puntuaciones. Traslada esas comprobaciones al servidor.

5. Sin vuelta atrás

Un cambio erróneo o una persona malintencionada puede borrar datos. Si no hay copia de seguridad ni forma de deshacer, un pequeño error se convierte en uno permanente. Asegúrate de que tu herramienta tenga puntos de control para el código y copias de seguridad para la base de datos. Consulta cómo hacer una copia de seguridad de la base de datos de tu app.

Gestionar los secretos de forma correcta

Los secretos causan más daños evitables que nada más, así que aquí están las reglas en un solo lugar:

• Nunca pegues una clave real en el chat. Los chats se guardan, se comparten y se capturan en pantalla. Guarda las claves en los secretos o variables de entorno de tu herramienta. (Qué son las variables de entorno y los secretos.)
• Llama a los servicios de pago desde el servidor. El navegador le pide algo a tu servidor; tu servidor llama al servicio de IA o de pagos con la clave.
• Usa claves distintas para pruebas y para uso real, así una clave de prueba filtrada no puede tocar dinero real.
• Establece límites de gasto en los paneles de los proveedores de IA y de correo.
• Renueva una clave de inmediato si crees que se ha filtrado. Crea una nueva, actualiza el secreto y luego borra la antigua.

En Mythex, los secretos viven en la configuración del proyecto, fuera del código, y el agente puede usarlos sin que los valores aparezcan en el chat. Nuestra guía sobre cómo mantener seguras las claves de API cubre más proveedores.

¿Cuánta revisión de código necesitas?

Hacer vibe coding significa que no lees cada línea. No hace falta. Pero en algunas líneas sí debería mirarlas alguien.

• Herramientas personales: nada más allá de las comprobaciones de esta página.
• Apps con cuentas de usuario: revisa cómo funcionan el inicio de sesión y el acceso a los datos. Puedes hacerlo pidiéndole a la IA que lo explique con palabras sencillas y comprobando que la explicación coincide con lo que esperas.
• Apps con pagos o datos sensibles: pide a una persona desarrolladora que revise la autenticación, los permisos, el manejo de pagos y cualquier cosa que guarde datos personales. Son unas horas de su tiempo, no una reescritura.

Un prompt útil incluso sin desarrollador:

Explica, con palabras sencillas, cómo decide esta app quién es un usuario y qué puede ver. Señala los archivos. Después enumera lo que revisaría una persona especialista en seguridad.

Nuestra guía sobre cómo revisar código generado por IA explica qué busca una persona revisora, y puedes dársela a quien haga la revisión. Si tu herramienta permite exportar el código o sincronizarlo con GitHub, organizar esa revisión es fácil; en Mythex, ambas cosas forman parte del plan Pro.

La comprobación de 30 minutos antes de publicar

Hazla antes de compartir el enlace con alguien fuera de tu círculo.

Acceso (10 minutos)

1. Dos cuentas, dos navegadores: ¿puede B abrir los registros de A con la URL? No debería.
2. Cierra sesión y visita directamente la dirección de cada página. Las páginas privadas deberían llevarte al inicio de sesión.
3. Como usuario normal, intenta abrir las direcciones de administración. Deberían denegarse.

Secretos (5 minutos)

1. Pregúntale a la IA dónde vive cada clave, usando el prompt de arriba.
2. Abre la app, ve el código fuente de la página y busca «key», «secret» y «token».

Formularios y abusos (5 minutos)

1. Envía cada formulario vacío, con textos muy largos y dos veces seguidas.
2. Confirma que existen límites de peticiones en el registro, el inicio de sesión y cualquier función de IA.

Datos y recuperación (5 minutos)

1. Sabe dónde están los datos y cómo restaurarlos.
2. Comprueba que puedes volver el código a una versión anterior que funcionara.

Legal y lo básico (5 minutos)

1. Si recoges datos personales, añade una política de privacidad y di qué recoges. Consulta cómo redactar términos de servicio y una política de privacidad.
2. Asegúrate de que la app publicada usa HTTPS. La mayoría de los creadores, Mythex incluido, se encargan de esto por ti.

Si todo pasa, estás en buena forma para un lanzamiento temprano. Repite los pasos 1 a 5 después de cualquier cambio importante en el inicio de sesión, los roles o los datos.

Qué protegen y qué no protegen las plataformas de vibe coding

Una buena plataforma se encarga de buena parte de la infraestructura: HTTPS, espacios de trabajo aislados, una base de datos por proyecto, almacenamiento de secretos, copias de seguridad y vuelta atrás. Mythex da a cada proyecto su propio espacio de trabajo y base de datos privados, mantiene los secretos fuera del código y guarda un punto de control después de cada cambio exitoso para que puedas deshacerlo.

Lo que ninguna plataforma puede hacer es conocer las reglas de tu app. Solo tú sabes que los clientes no deberían ver las facturas de otros, o que un cupón debería funcionar una sola vez. Esas reglas tienen que estar en tus prompts y confirmarse con tus pruebas.

La respuesta corta

El vibe coding es tan seguro como las comprobaciones que le añadas. Para una herramienta personal, mantén las claves fuera del código y disfruta. Para cualquier cosa con datos de otras personas, haz la comprobación de 30 minutos de arriba antes de cada lanzamiento y pide la opinión de una persona desarrolladora para pagos y datos sensibles. Para ver estos riesgos en proyectos reales, lee nuestros ejemplos de vibe coding; para crear con estas comprobaciones desde el principio, sigue cómo crear una app con vibe coding.

Preguntas