El OWASP Top 10 es la referencia más citada en seguridad de aplicaciones web. La edición 2025, la octava de la lista, es la versión oficial publicada por OWASP y trae cambios relevantes respecto a 2021: dos categorías nuevas, una fusión y varios cambios de posición. A continuación: cada categoría, qué cambió y cómo usar la lista sin tratarla como un checklist completo.
Qué es el OWASP Top 10
La propia OWASP define el Top 10 como un documento de concienciación: un consenso amplio sobre los riesgos más críticos para las aplicaciones web. Cada categoría agrupa varias debilidades del catálogo CWE, mantenido por MITRE, bajo un nombre común. En la edición 2025, las diez categorías reúnen 248 CWE.
La metodología está "informada por datos, pero no ciegamente guiada por ellos". Ocho categorías provienen de datos de pruebas aportados por empresas e investigadores que, según OWASP, cubren más de 2,8 millones de aplicaciones. Las otras dos provienen de una encuesta a profesionales del área, para captar riesgos que las herramientas todavía no pueden medir a escala.
Las diez categorías de la edición 2025
- A01 – Broken Access Control (control de acceso roto). El usuario puede actuar fuera de los permisos que debería tener: ver datos de otro cliente, acceder a funciones administrativas, modificar registros ajenos. Sigue en primer lugar y ahora incluye el SSRF.
- A02 – Security Misconfiguration (configuración insegura). Valores por defecto inseguros, servicios y cuentas innecesarios, mensajes de error detallados, cabeceras ausentes, almacenamiento en la nube mal configurado. Crece a medida que más comportamiento de la aplicación depende de la configuración.
- A03 – Software Supply Chain Failures (fallas en la cadena de suministro de software). Compromisos o debilidades en el proceso de construir, distribuir o actualizar software: dependencias vulnerables o abandonadas, cambios maliciosos en componentes de terceros, pipelines de build sin control.
- A04 – Cryptographic Failures (fallas criptográficas). Ausencia de cifrado donde es necesario, algoritmos débiles, claves mal gestionadas o datos sensibles transmitidos y almacenados en texto claro.
- A05 – Injection (inyección). Datos no confiables interpretados como comando o consulta. Va desde el Cross-site Scripting, frecuente y en general de menor impacto, hasta la SQL Injection, menos frecuente y de alto impacto.
- A06 – Insecure Design (diseño inseguro). Fallas que nacen en la arquitectura y la lógica de negocio, no en la implementación: un flujo sin límite de intentos o una regla de negocio que se puede eludir.
- A07 – Authentication Failures (fallas de autenticación). Contraseñas débiles aceptadas, sin protección contra ataques automatizados de credenciales, sesiones mal gestionadas, recuperación de cuenta frágil.
- A08 – Software or Data Integrity Failures (fallas de integridad de software o de datos). La aplicación confía en código, actualizaciones o datos sin verificar su integridad, como la deserialización insegura o actualizaciones automáticas sin firma.
- A09 – Security Logging and Alerting Failures (fallas de registro y alerta). Los eventos relevantes no se registran, o se registran sin que nadie reciba una alerta. Un log sin alerta ayuda poco a detectar un incidente.
- A10 – Mishandling of Exceptional Conditions (manejo inadecuado de condiciones excepcionales). La aplicación no previene, no detecta o responde mal a situaciones anormales: errores que filtran información, excepciones no manejadas, lógica que "falla abierta" y concede acceso cuando algo sale mal.
Qué cambió respecto a 2021
- Dos categorías nuevas. A03, Software Supply Chain Failures, amplía la antigua A06:2021 (Vulnerable and Outdated Components) a toda la cadena de dependencias, build y distribución. Según OWASP, fue el riesgo más votado en la encuesta a la comunidad y tiene las puntuaciones medias de explotación e impacto más altas entre los CVE analizados. A10, Mishandling of Exceptional Conditions, es inédita y reúne debilidades de manejo de excepciones y de lógica antes dispersas en "calidad de código".
- Una fusión. El Server-Side Request Forgery, que era la A10:2021, se incorporó a la A01, Broken Access Control.
- Lo que subió. Security Misconfiguration pasó del 5.º al 2.º lugar.
- Lo que bajó. Cryptographic Failures cayó del 2.º al 4.º, Injection del 3.º al 5.º e Insecure Design del 4.º al 6.º. En el caso de Insecure Design, OWASP atribuye parte de la caída a los avances del sector en modelado de amenazas.
- Mismo lugar, otro nombre. A07 perdió el "Identification" del nombre (era Identification and Authentication Failures). A09 cambió "Monitoring" por "Alerting", para subrayar que registrar sin alertar no basta. A08 mantuvo su posición.
Bajar en el ranking no significa que el riesgo esté resuelto: según OWASP, la inyección sigue siendo la categoría con más CVE asociados.
Cómo usar el Top 10 (y cómo no usarlo)
OWASP es explícita: el Top 10 es un punto de partida, no una lista completa. Desaconseja cualquier afirmación de "cobertura total del OWASP Top 10", incluso por parte de fabricantes de herramientas, porque categorías como Insecure Design no pueden detectarse de forma automatizada.
- Concienciación y formación. Es donde el Top 10 brilla: dar a desarrolladores, producto y dirección un vocabulario común sobre los riesgos más relevantes.
- Requisitos y verificación. Para un estándar verificable, la recomendación de la propia OWASP es el ASVS (Application Security Verification Standard), hoy en la versión 5.0.0, con requisitos organizados por niveles que pueden incorporarse a historias de usuario, criterios de aceptación y contratos con proveedores.
- Pruebas. El WSTG (Web Security Testing Guide) describe cómo probar cada área de una aplicación web y es la metodología de referencia para el pentest de aplicaciones.
En una frase. Use el Top 10 para saber dónde mirar primero, el ASVS para definir qué exigir y el WSTG para definir cómo probar.
Cómo probar una aplicación frente a estos riesgos
Ninguna técnica por sí sola cubre las diez categorías:
- SAST (análisis estático). Examina el código fuente en busca de patrones inseguros, como entradas concatenadas en consultas o criptografía débil. Se ejecuta temprano en el pipeline, pero genera falsos positivos y no entiende las reglas de negocio.
- SCA e inventario de componentes. Identifica las bibliotecas y versiones en uso, incluidas las dependencias transitivas. Es la base para tratar la A03, junto con controles sobre el pipeline de build.
- DAST (análisis dinámico). Prueba la aplicación en ejecución, de afuera hacia adentro. Bueno para inyección, configuración y cabeceras; débil para la autorización entre usuarios y la lógica de negocio.
- Revisión manual de código. Encuentra lo que las herramientas no ven: una verificación de permisos ausente en un endpoint, un manejo de excepciones que falla abierto, una decisión de diseño insegura.
- Pentest de aplicaciones. Los testers explotan la aplicación como lo haría un atacante, siguiendo una metodología como el WSTG, con foco en lo que las herramientas automáticas detectan mal: control de acceso (A01), autenticación (A07), lógica de negocio y condiciones excepcionales (A10). En modalidad gray box, con credenciales de distintos perfiles, es la forma más directa de demostrar si un usuario puede acceder a los datos de otro.
Hay riesgos que solo se evalúan conversando con las personas y observando el proceso. La propia OWASP recuerda que verificar si el registro y la alerta funcionan de verdad (A09) exige entrevistas y evidencias de respuesta a incidentes, y que el diseño inseguro (A06) está fuera del alcance de la mayoría de las pruebas. Por eso, el modelado de amenazas en la fase de diseño y la integración de los logs de la aplicación al monitoreo de seguridad completan el cuadro.
Vea también pentest o escaneo de vulnerabilidades y cómo priorizar vulnerabilidades con CVSS, EPSS y KEV.
Preguntas frecuentes
¿La edición 2025 del OWASP Top 10 ya es la versión oficial?
Sí. El sitio oficial de OWASP presenta el Top 10:2025 como la edición publicada, con las diez categorías A01 a A10 descritas en este artículo. La edición 2021 sigue disponible para consulta y comparación.
¿Cumplir con el OWASP Top 10 garantiza que mi aplicación es segura?
No. El Top 10 cubre los riesgos más críticos, no todos, y OWASP lo describe como el mínimo. Para un estándar de requisitos completo y verificable, use el ASVS; para la metodología de pruebas, el WSTG.
¿Una herramienta automatizada puede cubrir todo el Top 10?
No. La propia OWASP afirma que las herramientas no pueden detectar, probar ni proteger de forma integral frente a todas las categorías, en especial Insecure Design. Las herramientas son esenciales para la escala; la revisión manual y el pentest cubren lo que ellas no alcanzan.
Fuentes consultadas: OWASP, OWASP Top 10:2025 (introducción, páginas de cada categoría, "Establishing a Modern Application Security Program" y "Next Steps"); OWASP, OWASP Top 10:2021; OWASP Application Security Verification Standard (ASVS) 5.0.0; OWASP Web Security Testing Guide (WSTG); MITRE, Common Weakness Enumeration (CWE). Este artículo es educativo; consulte el texto oficial de OWASP para la descripción completa de cada categoría y de las CWE asociadas.