Las 10 vulnerabilidades de código que debes buscar en 2026

La mayoría de las brechas de seguridad siguen empezando por un puñado de clases de bugs bien conocidas. Los frameworks se volvieron más seguros, pero los errores se desplazaron: a los handlers de API, a los jobs en segundo plano, al código de infraestructura y al pegamento entre servicios. Esta es la lista que revisamos primero en cada auditoría, con el CWE que verás en un informe de CodeAuditAgent.

1. Control de acceso roto (CWE-639, CWE-862)

Es, con diferencia, el hallazgo grave más común: un endpoint carga un registro por su ID sin comprobar que pertenece a quien hace la petición. La autenticación te dice quién es alguien; la autorización tiene que aplicarse en cada consulta, sin excepción.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Inyección (CWE-89, CWE-78)

El SQL construido concatenando strings, los comandos de shell y las expresiones de plantilla siguen por todas partes, normalmente en esa única consulta que alguien escribió a mano por rendimiento. Parametriza la consulta o pasa los argumentos como un array; nunca concatenes la entrada del usuario.

3. Secretos hardcodeados (CWE-798)

Claves de API subidas al repositorio, tokens de prueba que resultaron ser reales, claves privadas en archivos de configuración. Muévelos a variables de entorno o a un gestor de secretos, y rota todo lo que se haya commiteado alguna vez: borrar la línea no borra el historial.

4. Server-side request forgery (CWE-918)

Cualquier funcionalidad que descargue una URL proporcionada por el usuario, como webhooks, vistas previas de enlaces o importaciones, puede apuntarse a tu red interna o al endpoint de metadatos de la nube. Usa una allowlist de hosts, resuelve y verifica la IP, y bloquea los rangos privados.

5. Cross-site scripting (CWE-79)

Los frameworks modernos escapan la salida por defecto, así que el XSS ahora se esconde en las vías de escape: props de HTML sin procesar, renderizadores de markdown y URLs colocadas en atributos href. Sanea el HTML con una librería de confianza y rechaza las URLs javascript:.

6. Deserialización insegura y eval (CWE-502, CWE-95)

Pickle, la carga de YAML, los object streams de Java y el eval dinámico convierten datos en código. Usa loaders seguros y JSON validado con un esquema.

7. Criptografía débil (CWE-327, CWE-330)

MD5 o SHA-1 para contraseñas, IVs estáticos, Math.random() para tokens. Usa un hash de contraseñas diseñado para ello (Argon2id, bcrypt, scrypt) y una fuente de aleatoriedad criptográficamente segura.

8. Redirecciones abiertas (CWE-601)

Un parámetro next o returnTo que acepta cualquier URL convierte tu dominio en una plataforma de confianza para el phishing. Acepta solo rutas relativas del mismo origen.

9. Falta de rate limiting (CWE-307, CWE-770)

El login, el restablecimiento de contraseña, los OTP y cualquier endpoint que te cueste dinero (email, SMS, llamadas a IA) necesitan límites por usuario y por IP. Sin ellos, los ataques de fuerza bruta y los que disparan tu factura son triviales.

10. Configuración de seguridad incorrecta (CWE-16)

CORS con comodín y credenciales, modo debug en producción, stack traces detallados, políticas de buckets demasiado permisivas. Rara vez parecen bugs en una code review porque viven en la configuración, y precisamente por eso deben revisarse como si fueran código.

Cómo usar esta lista

• Revisa las clases 1 a 3 en cada pull request; son las de mayor impacto y las más fáciles de pasar por alto.
• Trata la configuración de infraestructura y de CI como código sujeto a revisión.
• Registra el CWE en cada hallazgo para poder hacer seguimiento de las correcciones y medir tendencias.