Riesgos de seguridad del vibe coding: 8 aspectos que revisar antes de lanzar

«Vibe coding» significa crear software describiendo a una IA lo que se desea y aceptando lo que produce. Ha puesto la creación de aplicaciones al alcance de fundadores, diseñadores y operadores que hace uno o dos años no sabían programar. También ha creado un nuevo tipo de brecha de seguridad: software que funciona, parece terminado y nunca fue revisado por alguien que piense como un atacante.

Esta guía enumera los ocho riesgos de seguridad que revisaríamos primero en una aplicación creada con vibe coding, por qué ocurre cada uno y qué hacer al respecto. Ninguno requiere que usted lea código. Requieren que haga las preguntas correctas antes de que lleguen los usuarios reales.

Por qué las aplicaciones generadas con IA tienen un perfil de riesgo propio

Las herramientas de IA optimizan para que «funcione». Si una solicitud falla por un permiso, la forma más rápida de hacerla funcionar suele ser eliminar el permiso. Si hace falta una clave de API, el lugar más rápido para ponerla es donde el código pueda alcanzarla, que puede ser el navegador. La aplicación supera todas las pruebas que ejecuta quien la construye, porque esas pruebas se ejecutan como propietario.

Por eso las debilidades que siguen rara vez son errores de código espectaculares. Son decisiones que faltan: quién puede hacer esto, dónde debe guardarse este secreto, qué pasa si alguien hace un mal uso de esta función.

Riesgo 1: control de acceso roto

El problema más común y más grave. Un cliente puede leer, modificar o eliminar los registros de otro, o un usuario normal puede acceder a funciones de administración, porque las comprobaciones existen solo en la interfaz y no en el servidor ni en la base de datos. En los proyectos de Supabase esto suele significar una Row Level Security ausente o débil, que tratamos en siete errores de RLS que cometen las aplicaciones creadas con IA.

Prueba: use dos cuentas e intente acceder a los datos de la otra cambiando los ID en las URL y en las solicitudes.

Riesgo 2: secretos expuestos

Las claves de API, las contraseñas de bases de datos y los tokens de servicio acaban en el código del frontend, en repositorios públicos o en transcripciones de chat. Todo lo que se envía al navegador es público, y las claves incluidas en Git permanecen en el historial incluso después de eliminar el archivo.

Solución: guarde los secretos en variables de entorno del lado del servidor, busque claves en su bundle y en su repositorio, y rote todo lo que haya estado expuesto alguna vez.

Riesgo 3: entradas sin validar

Los formularios, las URL y los parámetros de API están controlados por el atacante. Si la aplicación construye consultas a la base de datos uniendo cadenas de texto, o imprime la entrada del usuario en las páginas sin codificarla, puede quedar expuesta a inyección SQL o a cross-site scripting. Los frameworks y constructores de consultas modernos evitan la mayor parte de esto por defecto, pero el código generado a veces los esquiva.

Solución: utilice consultas parametrizadas, valide la entrada en el servidor y revise todos los lugares donde se construyan consultas en bruto o HTML en bruto.

Riesgo 4: dependencias alucinadas y obsoletas

A veces las herramientas de IA sugieren paquetes de software que no existen. Los atacantes han empezado a registrar esos nombres, con código malicioso dentro, con la esperanza de que un desarrollador o una herramienta automatizada los instale. A veces se denomina slopsquatting. Por otra parte, los proyectos generados suelen fijar versiones antiguas con vulnerabilidades conocidas.

Solución: compruebe que cada dependencia exista, sea de uso extendido y sea la que usted pretendía, incluya su archivo de bloqueo (lockfile) en el repositorio y ejecute un análisis de vulnerabilidades de dependencias en cada compilación.

Riesgo 5: valores predeterminados inseguros

Algunos ejemplos son una configuración de origen cruzado permisiva que permite a cualquier sitio llamar a su API, el modo de depuración activado en producción, mensajes de error detallados que revelan detalles internos, buckets de almacenamiento públicos y cuentas de administrador predeterminadas. Cada uno se corrige con un cambio de una línea y cada uno es fácil de pasar por alto.

Solución: revise la configuración de producción por separado de la de desarrollo y desactive todo lo que exista solo por comodidad.

Riesgo 6: sin límites de uso ni de coste

Las aplicaciones con funciones de IA suelen llamar a un modelo de pago en nombre de cada visitante. Sin límites de frecuencia, cuotas por usuario ni topes de gasto, un script puede generar una factura enorme o dejar el servicio fuera de línea. Los formularios de inicio de sesión y de registro sin límites invitan a adivinar contraseñas y a registros automatizados por bots.

Solución: añada limitación de frecuencia, establezca topes de uso en cada clave de terceros y active alertas cuando el gasto se dispare.

Riesgo 7: inyección de prompts en sus propias funciones de IA

Si su aplicación permite que un modelo lea contenido de los usuarios, navegue por páginas o llame a herramientas, los atacantes pueden ocultar instrucciones en ese contenido para dirigir al modelo. El peligro aumenta con lo que el modelo puede hacer: leer datos privados, enviar mensajes o modificar registros. Explicamos los tipos de ataque y las pruebas en nuestra guía sobre red teaming de LLM frente a una prueba de penetración de aplicaciones web.

Solución: otorgue a las herramientas del modelo el mínimo privilegio posible, exija aprobación humana para las acciones de riesgo y trate todo lo que el modelo produzca como no confiable.

Riesgo 8: sin registros, no hay forma de saberlo

Muchas aplicaciones creadas con vibe coding no pueden responder a preguntas básicas cuando algo sale mal: quién accedió a qué, cuándo empezó el error, qué solicitud falló. Sin registros ni monitorización, un incidente puede prolongarse durante semanas sin que nadie lo note, y usted no puede determinar qué quedó expuesto.

Solución: centralice los registros de errores, conserve registros de auditoría de las acciones sensibles y configure alertas que lleguen a una persona real.

Una revisión de seguridad de 30 minutos que puede hacer hoy

1. Cree dos cuentas de prueba e intente ver, modificar y eliminar los datos de la otra.
2. Busque en su repositorio y en el código compilado de su sitio web claves de API y tokens de servicio.
3. Compruebe qué buckets de almacenamiento y tablas de la base de datos son legibles públicamente.
4. Abra las solicitudes de red de su aplicación y busque secretos, URL internas o errores detallados.
5. Enumere cada dependencia y confirme que es real, actual y la prevista.
6. Confirme que existen límites de frecuencia y topes de gasto en el inicio de sesión, el registro y cualquier función de IA.
7. Compruebe que los errores y las acciones sensibles se registran en algún lugar que usted pueda leer.

Lo que las herramientas de IA pueden y no pueden hacer al respecto

Puede pedirle a la IA que revise su propio código en busca de estos problemas, y encontrará algunos. Pero trabaja con las mismas suposiciones que originaron el problema y no puede probar su sistema desplegado con dos cuentas reales. Trate una revisión de seguridad hecha por IA como una primera pasada, no como una autorización.

Cuando hay usuarios reales, datos personales o pagos en juego, recurra a alguien independiente. Una auditoría técnica de aplicaciones de IA cubre el control de acceso, los secretos, los permisos de datos, los pagos y el despliegue, y termina con una lista de correcciones priorizada. Si ya sabe qué falla, la reparación y lanzamiento a producción de aplicaciones de IA lo corrige y lo publica de forma controlada. Nuestra lista de verificación de producción de 20 puntos une todas estas comprobaciones.