Seguridad en apps hechas con IA: los errores que más se repiten

Los fallos de seguridad más comunes en apps creadas con vibe coding (permisos, claves expuestas, dependencias, inyección) y una lista de revisión antes de publicar, basada en OWASP Top 10:2025.

Publicado el 2026-07-06 · actualizado el 2026-10-02 · 5 min de lectura

En resumen

El código generado por IA suele funcionar, pero no siempre es seguro: en un estudio de Veracode de 2025, los modelos eligieron la opción insegura en el 45 % de las tareas analizadas.
El fallo número uno de la lista OWASP Top 10:2025 es el control de acceso roto: usuarios que pueden ver o cambiar datos que no son suyos.
Los otros errores típicos: claves secretas en el código, dependencias sin revisar, entradas sin validar y configuración por defecto.
Antes de publicar, prueba tu app con dos cuentas, busca secretos en el repositorio y pide a la IA una revisión de seguridad específica.

Por qué las apps hechas con IA tienen fallos de seguridad

Cuando pides una función, la IA optimiza para que funcione. La seguridad suele ser invisible en la demo: una tabla que cualquiera puede leer se ve igual que una protegida hasta que alguien la lee.

Veracode analizó en 2025 el código generado por más de 100 modelos en 80 tareas y encontró que, cuando había una forma segura y otra insegura de resolver la tarea, los modelos eligieron la insegura en el 45 % de los casos. No significa que la IA programe mal; significa que, si no pides seguridad y no la revisas, no está garantizada.

Error 1: control de acceso roto

Es el primero de la lista OWASP Top 10:2025 y el más común en apps hechas rápido. Ejemplos:

Cambias el número en la URL (/factura/123 a /factura/124) y ves la factura de otra persona.
La base de datos se consulta desde el navegador sin reglas de acceso por fila.
El botón de administrador está oculto en la interfaz, pero el endpoint no comprueba quién lo llama.

La regla: cada consulta y cada acción se autoriza en el servidor (o con políticas en la base de datos, como Row Level Security en Postgres), nunca solo ocultando cosas en la interfaz.

Error 2: claves secretas expuestas

La clave de la API de pagos o del modelo de IA está en el código del frontend, donde cualquiera puede verla.
El archivo .env se subió a GitHub.
La clave se pegó en un chat o en una captura.

Las claves van en variables de entorno del servidor y en el panel de tu hosting. Las llamadas que necesitan una clave secreta pasan por tu backend. Si una clave se expuso, revócala y crea otra: borrarla del repositorio no basta, porque queda en el historial.

Error 3: dependencias sin revisar

OWASP añadió en 2025 una categoría nueva, fallos en la cadena de suministro de software. Las apps hechas con IA instalan muchas librerías, y a veces la IA sugiere paquetes que no existen o que están abandonados.

Comprueba que cada paquete existe, tiene mantenimiento y es el que crees (cuidado con nombres parecidos).
Usa un archivo de bloqueo (package-lock.json) e instala con npm ci en tus despliegues.
Revisa periódicamente con npm audit y activa las alertas de dependencias de GitHub.

Error 4: confiar en lo que entra

Todo lo que llega de fuera (formularios, parámetros de la URL, archivos subidos, respuestas de otros servicios) puede ser malicioso.

Valida en el servidor el tipo, la longitud y el formato de cada dato.
Usa consultas parametrizadas o un ORM para evitar inyección SQL.
No insertes HTML que venga del usuario sin escaparlo.
Si tu app usa un modelo de IA, ten en cuenta la inyección de instrucciones: un texto puede intentar darle órdenes al modelo.

Error 5: configuración por defecto

Mensajes de error que muestran rutas internas o consultas SQL.
Modo de desarrollo activo en producción.
Sin cabeceras de seguridad (Content-Security-Policy, HSTS, X-Content-Type-Options).
Sin límite de intentos en el inicio de sesión.

Lista de revisión antes de publicar

Crea dos cuentas de prueba e intenta ver o cambiar con una los datos de la otra.
Busca secretos en el repositorio y en el código del navegador (DevTools, pestaña de fuentes).
Ejecuta npm audit y revisa las dependencias que no reconozcas.
Prueba los formularios con datos vacíos, muy largos o con caracteres especiales.
Revisa las cabeceras de seguridad de tu dominio.
Pide a la IA: «actúa como un auditor de seguridad; revisa este endpoint según OWASP Top 10 y dime cómo lo atacarías».
Apunta lo que encontraste y lo que corregiste.

Aprende seguridad con práctica

La ruta Seguridad y acceso de Codelindo cubre autenticación, permisos, secretos, dependencias y buenas prácticas, con retos donde encuentras el fallo. El proyecto final es la auditoría de seguridad de tu propia app: permisos probados con dos cuentas, secretos fuera del repositorio, cabeceras activas y un informe de lo que corregiste. Está incluida en el plan Pro.

Preguntas frecuentes

¿Las apps hechas con IA son inseguras?

No por definición, pero la seguridad no viene incluida. Si no la pides y no la revisas, es fácil publicar fallos como permisos rotos o claves expuestas.

¿Qué es OWASP Top 10?

La lista de los riesgos de seguridad más críticos en aplicaciones web, publicada por la fundación OWASP. La edición actual es la de 2025.

¿Qué hago si subí una clave a GitHub?

Revócala en el panel del proveedor y crea una nueva de inmediato. Después quítala del código. Borrarla del repositorio no basta: queda en el historial.

¿La IA puede revisar la seguridad de mi código?

Sí, y conviene pedírselo de forma explícita y específica. Es una ayuda, no un sustituto de probar tú mismo los permisos con dos cuentas.

Siguiente paso: curso de seguridad web.