Seguridad básica para quien hace vibe coding: lo que no puede faltar

Qué revisar antes de publicar una app generada con IA: control de acceso, claves, validación de datos y dependencias, con una lista corta y fuentes abiertas.

info Definición Rápida
La seguridad básica en vibe coding es un conjunto corto de comprobaciones que cualquier persona puede hacer antes de publicar una app generada con IA: quién puede ver qué, dónde viven las claves, qué datos se validan y qué dependencias se usan. No reemplaza una auditoría, pero cubre los errores más frecuentes.

¿Por qué el riesgo es alto?

Una IA genera código que funciona. Eso no significa que sea seguro. Veracode publicó en julio de 2025 un estudio con más de 100 modelos de lenguaje y 80 tareas de programación: en el 45% de los casos de prueba el código generado introdujo vulnerabilidades del OWASP Top 10. Los modelos fallaron al proteger contra cross-site scripting (CWE-80) en el 86% de los casos, y en Java la tasa de fallos superó el 70% (Veracode, julio de 2025). Son tareas controladas y es un estudio de una empresa de seguridad, no una medición de tu app. Aun así, basta para tomar la revisión en serio.

El marco de referencia para aplicaciones web es el OWASP Top 10. Su edición 2025 lista, entre otras categorías, control de acceso roto, mala configuración de seguridad, fallas en la cadena de suministro de software, inyección y fallas de autenticación (OWASP Top 10:2025). Las comprobaciones siguientes cubren las que más afectan a quien construye sin escribir cada línea a mano.

¿Un usuario puede ver los datos de otro?

Es la primera pregunta, porque el control de acceso roto encabeza la lista de OWASP. Su ejemplo clásico es una dirección con un parámetro acct que lleva el número de cuenta: si el servidor no comprueba de quién es, cambiar ese valor basta para ver la cuenta de otra persona (OWASP, A01:2025). OWASP también establece dos reglas: denegar por defecto, salvo lo público, y hacer cumplir el acceso en código de servidor de confianza, no en el navegador.

Prueba con dos cuentas distintas y cambia identificadores en la dirección. Ocultar un botón no cuenta como regla.

Si tu app usa Supabase y consulta la base desde el navegador, la regla vive en la base de datos con Row Level Security (RLS). Su documentación dice que una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol con permisos sobre ella, y que con RLS activado no se accede a ningún dato con la clave publicable hasta que creas políticas (Supabase, Row Level Security). Pide a la IA que active RLS y que escriba políticas por usuario, y compruébalas con dos cuentas. El detalle está en bases de datos para diseñadores y frontend vs. backend.

¿Dónde viven las claves y qué hago si una se filtra?

Ninguna clave privada debe estar en el código que llega al navegador. La misma documentación de Supabase dice que una clave secreta nunca debe usarse en el navegador ni exponerse a los clientes. Busca en el proyecto palabras como key, token o secret, y revisa las variables con prefijo público, que acaban dentro del código del navegador. Qué clave puede ir ahí y cuál no está en variables de entorno y secretos.

Si una clave secreta ya estuvo publicada, GitHub recomienda considerarla comprometida. Lo más importante es revocarla en el servicio que la emitió; borrarla del código no basta, porque puede seguir en el historial del repositorio (GitHub, remediar un secreto filtrado). Si quitarla del servicio causaría una caída, GitHub sugiere crear primero una nueva con los mismos permisos y después revocar la anterior.

¿Cómo valido lo que escribe el usuario?

Todo lo que el usuario escribe puede ser cualquier cosa. Una prueba básica: escribe caracteres raros en cada campo (comillas, signos de menor, texto muy largo) y mira si la app se rompe o muestra algo que no debería.

La guía de validación de entradas de OWASP dice que se valida en el servidor aunque el navegador revise los mismos campos, y que conviene definir qué se acepta y rechazar el resto, en lugar de intentar reconocer cada texto malicioso. También separa la validación de las defensas contra la inyección: para SQL, consultas parametrizadas, y para XSS, codificar la salida según el contexto (OWASP, Input Validation Cheat Sheet). Si no sabes si tu código las usa, pregúntale a la IA dónde se arma cada consulta y dónde se muestra cada texto del usuario.

¿Qué hago con las dependencias?

Las librerías que la IA instala son código de terceros. OWASP incluye las fallas en la cadena de suministro de software (A03:2025) y recomienda llevar un inventario de componentes, incluidas las dependencias de las dependencias, y obtenerlos solo de fuentes oficiales (OWASP, A03:2025).

En la práctica: revisa qué paquetes se agregaron en cada cambio. Si aparece uno que no pediste o no conoces, pregunta por qué está y qué haría falta sin él.

¿Qué reviso en cada publicación?

Una lista de cinco minutos que puedes repetir:

  • ¿Dos cuentas ven solo sus datos y no pueden cambiar identificadores en la dirección?
  • ¿Hay claves secretas en archivos que descarga el navegador o en el repositorio?
  • ¿Los campos rechazan texto raro sin romper la app?
  • ¿Se agregaron dependencias que no reconoces?
  • ¿Hay un registro de errores que alguien revisa?

Si alguna respuesta es no, el cambio no está listo para usuarios reales. Guarda la fecha de cada revisión junto al proyecto: sin fecha no sabes cuándo repetirla. Addy Osmani recomienda tratar el código generado como el de una persona junior: necesita revisión y pruebas antes de entrar (Osmani, Beyond Vibe Coding).

Si el código no es tuyo y no lo entiendes, empieza por leer código sin saber programar. Si el agente corre en tu máquina, mira también sandboxing y permisos. Y si dudas de que el proyecto deba hacerse con vibe coding, revisa cuándo no hacer vibe coding.

Ejemplo

Ejemplo ilustrativo: una diseñadora publica una app para que sus clientes vean sus presupuestos. La demo sale bien. La lista de cinco minutos revela dos problemas: con dos cuentas, un cliente ve el presupuesto de otro cambiando el número en la dirección, y la clave del servicio de correo aparece en un archivo que descarga el navegador. Ella pide que el acceso se verifique en el servidor, mueve la clave a una variable de entorno que solo lee el servidor y revoca la clave anterior en el servicio de correo. Después repite la prueba con las dos cuentas. La demo no lo mostraba, pero la lista sí.

Errores comunes

  • Confiar en que la IA ya generó código seguro.
  • Revisar solo el camino feliz con una sola cuenta.
  • Ocultar un botón y pensar que la acción está restringida.
  • Borrar una clave del código sin revocarla en el servicio.
  • Validar solo en la pantalla.
  • Aceptar dependencias nuevas sin preguntar por qué están.
  • Publicar sin un plan para revisar errores después.

Fuentes

Preguntas frecuentes

¿Qué es lo primero que debo revisar en seguridad?
El control de acceso: que cada usuario vea y modifique solo lo suyo, y que esa regla se cumpla en el servidor o en la base de datos, no solo en la pantalla.
¿Qué pasa si una clave secreta queda en el código o en un repositorio?
Hay que tratarla como comprometida. Lo más importante es revocarla en el servicio que la emitió y crear una nueva; borrarla del archivo no basta, porque puede seguir en el historial del repositorio.
¿El código de la IA siempre tiene fallas de seguridad?
No siempre, pero el riesgo es real. En un estudio de Veracode de 2025, los modelos introdujeron vulnerabilidades en el 45% de los casos de prueba, así que la revisión no es opcional.
¿Basta con revisar la seguridad una vez?
No. Hay que revisar cada vez que cambian los permisos, los datos o las dependencias, y antes de cada publicación importante.