La lista no se arma por opinión, se arma con datos de la industria. Para leer esos datos hacen falta tres siglas.

• 13 organizaciones aportaron los resultados de sus pruebas sobre más de 2.8 millones de aplicaciones.
• Cada categoría del Top 10 agrupa varios CWE emparentados, 248 en total.
• Prevalencia: porcentaje de aplicaciones probadas donde se encontró al menos un error de esa categoría.
• Las categorías más prevalentes suben de posición en la lista.
• La gravedad de cada categoría sale de los CVE ya reportados y de sus puntajes CVSS.

• Corregir un defecto de seguridad en producción cuesta mucho más que evitarlo en diseño.
• La práctica actual es desplazar la seguridad hacia la izquierda del ciclo, lo que la industria llama shift left.
• La seguridad deja de ser una revisión final y se integra en cada etapa del proceso.

• A01 Broken Access Control — control de acceso roto
• A02 Security Misconfiguration — configuración de seguridad incorrecta
• A03 Software Supply Chain Failures — fallas en la cadena de suministro
• A04 Cryptographic Failures — fallas criptográficas
• A05 Injection — inyección

• A06 Insecure Design — diseño inseguro
• A07 Authentication Failures — fallas de autenticación
• A08 Software or Data Integrity Failures — fallas de integridad de software o datos
• A09 Security Logging and Alerting Failures — fallas de registro y alerta
• A10 Mishandling of Exceptional Conditions — manejo incorrecto de condiciones excepcionales

• Cuando falla, un atacante accede a datos ajenos, modifica información o ejecuta funciones de negocio que no le corresponden.
• Es la categoría número uno desde 2021 y en 2025 absorbió también el SSRF.

• Denegar por defecto todo recurso que no sea explícitamente público.
• Implementar el control de acceso del lado del servidor, nunca en el código del cliente.
• Validar la propiedad del registro en el modelo de dominio, no solo el rol del usuario.
• Registrar los intentos fallidos y aplicar límites de tasa en las API.
• Invalidar la sesión al cerrar sesión y usar tokens de vida corta.

• Subió del puesto 5 al puesto 2, impulsada por la complejidad de la nube, los contenedores y la infraestructura como código.

• Definir un proceso de endurecimiento repetible y automatizado para todos los ambientes.
• Mantener desarrollo, pruebas y producción configurados de forma equivalente.
• Eliminar componentes y funciones que no se usan.
• Revisar la configuración dentro del pipeline, no como tarea manual.

• Ya no se trata solo de usar una biblioteca con vulnerabilidades conocidas.
• Cubre todo el proceso de construir, distribuir y actualizar software.

• Mantener un SBOM del proyecto, el inventario de todo lo que se incluye.
• Fijar versiones exactas y verificar integridad con firmas o sumas de verificación.
• Monitorear bases de vulnerabilidades como CVE, NVD y OSV de forma continua.
• Obtener componentes solo de fuentes oficiales y por canales seguros.
• Usar autenticación multifactor y menor privilegio en repositorios y pipelines.

• Antes se llamaba Sensitive Data Exposure, un nombre que describía el síntoma.
• El nombre actual apunta a la causa raíz, que es el mal uso de la criptografía.

• Clasificar los datos y definir qué requiere cifrado según su sensibilidad.
• No almacenar datos sensibles que no sean necesarios.
• Usar TLS actualizado en todo tránsito y algoritmos vigentes en reposo.
• Almacenar contraseñas con Argon2, bcrypt o scrypt, con salt por usuario.
• Gestionar las claves en un servicio dedicado, con rotación definida.

• Incluye inyección SQL, NoSQL, de comandos del sistema operativo, LDAP y también Cross-Site Scripting.
• Bajó del puesto 3 al 5 porque los frameworks modernos ya traen defensas por defecto.

• Usar consultas parametrizadas o un ORM que las genere.
• Validar la entrada en el servidor con listas de permitidos.
• Escapar la salida según el contexto donde se inserta.
• Limitar los registros que devuelve una consulta, para acotar la fuga si el ataque tiene éxito.

• Hacer modelado de amenazas sobre los flujos críticos del sistema.
• Escribir casos de abuso junto a los casos de uso.
• Usar patrones de diseño seguros y componentes ya endurecidos.
• Separar por capas y por inquilinos según el nivel de exposición de cada parte.

• En 2025 cambió de nombre, de Identification and Authentication Failures a Authentication Failures.

• Implementar autenticación multifactor donde el riesgo lo justifique.
• Verificar las contraseñas contra listas de credenciales filtradas.
• Aplicar límites de intentos y retardos progresivos, registrando los fallos.
• Generar identificadores de sesión aleatorios del lado del servidor, con expiración explícita.

• Verificar firmas digitales en actualizaciones y artefactos.
• Evitar la deserialización de datos no confiables o restringirla a tipos conocidos.
• Usar Subresource Integrity al cargar recursos externos desde un CDN.
• Proteger el pipeline con revisión de cambios y segregación de funciones.

• En 2025 el nombre pasó de monitoring a alerting, para enfatizar que registrar no basta si nadie reacciona.

• Registrar inicios de sesión, fallos de acceso y transacciones de alto valor con contexto suficiente.
• Centralizar los registros y protegerlos contra alteración.
• Definir alertas accionables y quién responde a cada una.
• Tener un plan de respuesta a incidentes y ejercitarlo.

• La idea central es que el comportamiento del sistema cuando algo sale mal también es una decisión de diseño.

• Fallar de forma cerrada, denegando por defecto cuando la verificación no se completa.
• Devolver mensajes de error genéricos al usuario y el detalle solo al registro.
• Manejar cada excepción de forma explícita y probar las rutas de error.
• Usar transacciones para que una operación fallida no deje datos a medias.

• Injection e Insecure Design bajaron posiciones porque los frameworks resolvieron parte del problema.
• Configuración y cadena de suministro subieron porque hoy el software se ensambla más de lo que se escribe.