¿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 enfoque de «describirlo y ver 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 debes hacer antes de publicar.

Para la lista técnica completa, consulta nuestra lista de verificación de seguridad para apps creadas con IA. Esta página es la versión corta y práctica para quienes 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 o un usuario curioso que edita una dirección web.

Los modelos de IA escriben código verosímil, y la mayor parte está bien. Pero optimizan 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. Es pedir explícitamente esas 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 terminan en la tercera sin que nadie lo decida.

Los riesgos que de verdad causan problemas

1. Los usuarios pueden ver los datos de los demás

Este es el problema grave más común en las apps creadas con IA. La página muestra a cada usuario solo sus registros, así que parece correcto. 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 usuario A, abre uno de los registros de A y anota la dirección. Inicia sesión como usuario B en una ventana privada y pega esa dirección. Deberías ver «no encontrado», nunca los datos de A.

Prompt:

Revisa todos los endpoints del servidor que leen, modifican o eliminan datos de usuario. Cada uno debe confirmar que el usuario que ha iniciado sesión tiene acceso a ese registro concreto. Enumera los endpoints, explica cómo comprueba cada uno 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, dime dónde se guarda y si alguna vez se envía al navegador. Mueve a secretos 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 son encontrados por los bots. Sin límites, recibes spam, cuentas falsas o una factura enorme por una API de IA llamada miles de veces.

Prompt:

Añade límites de frecuencia 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. Dime los límites que has elegido.

4. Confiar en el navegador

Cualquier cosa que decida el navegador puede ser modificada por el usuario: precios, descuentos, respuestas de un cuestionario, indicadores de «es administrador». Las reglas que importan deben aplicarse en el servidor.

Prompt:

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

5. Sin forma de volver 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 tiene puntos de control para el código y copias de seguridad para la base de datos. Consulta cómo hacer copias de seguridad de la base de datos de tu app.

Cómo gestionar los secretos correctamente

Los secretos causan más daños evitables que cualquier otra cosa, así que aquí tienes 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, para que una clave de prueba filtrada no pueda tocar dinero real.
• Establece límites de gasto en los paneles de los proveedores de IA y de correo.
• Rota una clave de inmediato si crees que se ha filtrado. Crea una nueva, actualiza el secreto y luego elimina 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 tienes que hacerlo. Pero en algunas líneas alguien debería hacerlo.

• Herramientas personales: ninguna revisión 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 un desarrollador que revise la autenticación, los permisos, el manejo de pagos y cualquier parte que almacene datos personales. Son unas pocas 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é tiene permitido ver. Indica los archivos. Después enumera lo que querrías que revisara un especialista en seguridad.

Nuestra guía sobre cómo revisar código generado por IA explica lo que buscan los revisores, y puedes dársela a quien haga la revisión. Si tu herramienta permite exportar el código o sincronizar con GitHub, organizar esa revisión es sencillo; en Mythex, ambas cosas forman parte del plan Pro.

La revisión previa a la publicación de 30 minutos

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 deben llevarte al inicio de sesión.
3. Como usuario normal, intenta abrir las direcciones de administración. Deben rechazarte.

Secretos (5 minutos)

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

Formularios y abuso (5 minutos)

1. Envía cada formulario vacío, con textos muy largos y dos veces seguidas.
2. Confirma que existen límites de frecuencia 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 funcionaba.

Legal y básicos (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 inicial. Repite los pasos 1 a 5 después de cualquier cambio importante en el inicio de sesión, los roles o los datos.

Lo que protegen y lo que no protegen las plataformas de vibe coding

Una buena plataforma gestiona gran parte de la infraestructura: HTTPS, espacios de trabajo aislados, una base de datos por proyecto, almacenamiento de secretos, copias de seguridad y reversión. 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 tras 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 añadas. Para una herramienta personal, mantén las claves fuera del código y disfrútala. Para cualquier cosa con datos de otras personas, haz la revisión de 30 minutos de arriba antes de cada lanzamiento, y pide la opinión de un desarrollador 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