OWASP Top 10 2025 desde el pentest: qué cambia, qué cubre una auditoría web y qué añadir al alcance

Dos de las diez categorías del OWASP Top 10:2025 (la edición 2025 de la lista) no salen de los datos de pruebas sino de una encuesta a profesionales, y ningún pentest de caja negra las verifica por sí solo. Ese detalle, que los resúmenes de la nueva edición suelen pasar por alto, cambia lo que un informe de auditoría puede y no puede demostrar. La edición, la primera en cuatro años, se presentó en noviembre de 2025 y quedó cerrada en enero de 2026. El resto de cambios: dos categorías nuevas, una consolidación y una reordenación que baja el cifrado y la inyección dos puestos.

Este artículo mira la lista desde los dos lados de un encargo, el de quien audita y el de quien contrata: qué comprueba un pentester en cada categoría y cuáles solo se verifican con acceso al código, a la cadena de construcción o con el equipo de defensa presente. De ahí sale qué cambiar en el alcance de la próxima auditoría de aplicaciones web para que el informe cubra la lista entera y no solo las categorías que se pueden probar desde fuera. Sobre qué distingue al Top 10 de la guía de pruebas WSTG ya escribimos en metodologías de pentesting; aquí damos por sabida esa distinción.

Qué cambia en el OWASP Top 10 2025 respecto a 2021

La introducción oficial resume los movimientos. La pérdida de control de acceso sigue en el primer puesto, ahora con la falsificación de peticiones del lado del servidor (SSRF) absorbida dentro. La configuración de seguridad incorrecta sube del quinto al segundo. La categoría de fallos de la cadena de suministro de software es nueva y ocupa el tercero: amplía la antigua "componentes vulnerables y obsoletos" a todo el ecosistema de dependencias, sistemas de construcción y distribución.

Los fallos criptográficos bajan del segundo al cuarto y la inyección del tercero al quinto. El diseño inseguro cae al sexto. Fallos de autenticación (A07), fallos de integridad de software o datos (A08) y fallos de registro y alertas de seguridad (A09) mantienen sus puestos; A07 y A09 estrenan nombre. Y la décima es nueva: gestión incorrecta de condiciones excepcionales.

Los números que sostienen la lista importan tanto como el orden. Los datos proceden de más de 2,8 millones de aplicaciones aportadas por doce organizaciones identificadas y otras anónimas. Se analizaron 589 debilidades del catálogo CWE, frente a unas 400 en 2021, y las diez categorías agrupan 248 de ellas, con un tope de 40 por categoría.

Ocho categorías salen de los datos y dos las eligió la encuesta a la comunidad, por una razón que el documento expone sin rodeos: los datos miran al pasado, porque una debilidad tarda semanas o años en tener pruebas automatizadas fiables, y algunas quizá nunca las tengan.

Por qué dos categorías del OWASP Top 10 2025 vienen de una encuesta y qué significa para tu informe de pentest

Las dos categorías votadas son la cadena de suministro (A03) y el registro y las alertas (A09). La primera fue la más votada (la mitad de los encuestados la situó en el primer puesto). Aun así es la categoría con menos ocurrencias en los datos: solo 11 CVE asociados a sus debilidades, escasez que los autores atribuyen a la dificultad de probarla.

Cuando sí se prueba, es la categoría con mayor tasa media de incidencia, por encima del 5 % de las aplicaciones, y con las puntuaciones medias de explotabilidad e impacto más altas de toda la lista. La de registro y alertas (A09) tiende a estar infrarrepresentada por naturaleza: un registro que falta no genera un hallazgo.

Para el cliente de una auditoría, la implicación es clara. Un pentest de caja negra sobre una aplicación en producción no va a encontrar fallos de cadena de suministro ni de alertas, salvo por accidente, porque casi nunca se manifiestan en una petición HTTP. Si el informe de la última auditoría no menciona esas dos categorías, no es que la aplicación esté limpia; es que nadie las buscó. Y ese vacío es justo el que la comunidad pidió cubrir al votar esas dos categorías.

Qué cubre un pentest web del OWASP Top 10 2025, categoría a categoría

Categorías que un pentest web cubre bien

El control de acceso (A01) es la categoría donde el pentest rinde más y la que tiene más ocurrencias en los datos: referencias directas a objetos ajenos, navegación forzada a páginas de administración, controles implementados solo en el navegador, manipulación de tokens JWT o cookies, orígenes CORS demasiado abiertos. La prueba clásica sigue vigente: dos cuentas con roles distintos y una comprobación en ambas direcciones de que ninguna alcanza lo que no le corresponde, también con los verbos POST, PUT y DELETE de la API.

La configuración (A02), el cifrado (A04) y la inyección (A05) también se prueban bien desde fuera, con matices. En inyección, OWASP recuerda la asimetría: el XSS (cross-site scripting) es frecuente y de impacto bajo; la inyección SQL es rara y de impacto alto. Un informe con veinte XSS y ninguna SQLi no dice que la aplicación esté peor que otra con un solo hallazgo de inyección SQL. La autenticación (A07) se prueba con las técnicas habituales, y aquí el Top 10 aporta un dato que invita al optimismo: el mayor uso de marcos de autenticación estandarizados parece estar teniendo efectos beneficiosos.

La otra categoría nueva, gestión incorrecta de condiciones excepcionales (A10), agrupa 24 debilidades: mensajes de error que revelan información interna, parámetros ausentes o sobrantes mal gestionados, excepciones sin capturar, controles que ante un error dejan pasar (fail open) y transacciones que no se deshacen enteras. Un pentester las provoca a propósito: envía peticiones sin un parámetro obligatorio, fuerza errores de base de datos para ver qué devuelve el servidor, interrumpe una operación de varios pasos a mitad. Varias de estas debilidades se asociaban antes a la "mala calidad de código", según reconoce OWASP; ahora tienen categoría propia.

Lo que exige acceso al código o a la cadena de construcción

La cadena de suministro (A03) se verifica con inventario más que con peticiones: un SBOM generado de forma centralizada, análisis de composición de software que cubra las dependencias transitivas, y una revisión de cómo se construye y distribuye el artefacto.

El documento amplía el alcance respecto a 2021. Pide revisar el repositorio de código, los puestos de trabajo de los desarrolladores, el servidor de construcción, los repositorios de imágenes de contenedores y las extensiones del IDE. Y pide separación de funciones: nadie debería poder escribir código y pasarlo a producción sin la supervisión de otra persona. Ese alcance no cabe en un pentest web; cabe en una auditoría de código fuente o en una revisión de DevSecOps. Entre los ejemplos que cita OWASP está el gusano Shai-Hulud de npm de 2025, cuya variante posterior analizamos en el gusano autorreplicante de npm.

El diseño inseguro (A06) y la integridad de software o datos (A08) quedan entre ambos grupos. Un pentester detecta síntomas de diseño inseguro (una lógica de negocio que permite pedir cien unidades con precio negativo) pero no puede verificar que se hizo un modelado de amenazas; eso se revisa en documentación y entrevistas. La integridad se prueba parcialmente desde fuera (actualizaciones sin firma, deserialización de datos no confiables) y el resto desde dentro (integridad de la cadena de integración continua).

Registro y alertas (A09): solo se verifica con una prueba coordinada

El nuevo nombre de la categoría de registro y alertas (A09) apunta a una idea concreta: OWASP subraya que un registro excelente sin alertas tiene un valor mínimo. La forma más directa de verificar esta categoría es coordinar la prueba con quien vigila: el pentester ejecuta acciones que deberían generar alerta (fuerza bruta contra el inicio de sesión, fallos repetidos de control de acceso, una escalada). El equipo de defensa comprueba qué llegó al SIEM y qué reglas dispararon.

Es el mismo principio que aplicamos en ingeniería de detección: la cobertura sobre el papel no predice la detección. Un pentest que no incluya esa coordinación deja la categoría sin verificar, y el informe debería decirlo.

Cómo leer un informe de pentest con las categorías del Top 10 2025

El cambio metodológico que sostiene la edición es la apuesta por la causa raíz frente al síntoma. Los autores explican que "exposición de datos sensibles" o "denegación de servicio" son síntomas, mientras que "fallo criptográfico" o "configuración incorrecta" son causas, y que la lista se ha reorganizado para orientar mejor tanto la identificación como la corrección.

Para quien lee un informe, la consecuencia práctica es que la etiqueta de categoría dice menos que el identificador CWE: con 248 debilidades repartidas en diez categorías, dos hallazgos bajo A01 pueden ser un IDOR trivial y un SSRF hacia la red interna. Pide que cada hallazgo lleve su CWE y su CVSS, y deduce la severidad de esos campos; sobre cómo interpretarlos ya escribimos en cómo leer un informe de pentesting.

La segunda consecuencia es que la correspondencia entre 2021 y 2025 no es uno a uno. Un hallazgo de SSRF de 2023 estaba en A10; hoy está en A01. Un "componente obsoleto" de 2022 era A06; hoy es A03 con un alcance mucho mayor. Si comparas informes de distintos años por categoría, corrige primero la correspondencia o la comparación no tendrá sentido.

Qué cambiar en el alcance de la próxima auditoría web

En la práctica, el Top 10:2025 dice al cliente que una prueba de caja negra puede cubrir bien seis categorías (una de ellas, A10, solo si el alcance la nombra expresamente), cubre a medias dos y no cubre por sí sola ninguna de las dos que la comunidad votó para incluir. Completar la lista no exige un servicio distinto, sino nombrar en el alcance lo que falta: una revisión de dependencias y cadena de construcción con SBOM, una sesión coordinada con el equipo de defensa para validar alertas y un bloque explícito de manejo de errores y transacciones interrumpidas.

En Hard2bit Cybersecurity esa conversación sobre el alcance ocurre antes de firmar, no al entregar el informe, porque un pentest que devuelve "sin hallazgos" en una categoría que nadie probó es peor que uno que la deja fuera y lo dice. Si la aplicación expone API, la auditoría de API tiene criterios distintos, que se solapan con el Top 10 solo en parte.

Límites del Top 10 que hay que tener presentes

El propio documento se define como un documento de concienciación. Para verificar una aplicación con rigor, OWASP remite al ASVS y a la guía de pruebas WSTG, que descienden a requisitos y casos de prueba concretos.

Los datos, además, tienen sesgos que OWASP reconoce. Miden prevalencia por aplicación, así que una aplicación con 4 o con 4.000 instancias de una debilidad cuenta igual. Dependen de lo que las herramientas saben probar. Y las puntuaciones de explotabilidad e impacto se calculan con CVSS v2 y v3, porque la v4 ya no separa esas dos dimensiones. Es una lista excelente para priorizar y para explicar el riesgo a la dirección, y una mala lista de comprobación para auditar.

Hard2bit audita aplicaciones web y API desde 2013 con el OWASP Top 10 como mínimo y la WSTG como referencia de casos de prueba, con certificación ENS de categoría ALTA y cinco normas ISO, entre ellas la 27001:2022.

Este análisis tiene finalidad divulgativa y refleja el contenido del OWASP Top 10:2025 en su fecha de publicación; OWASP puede corregir cifras o textos en revisiones posteriores, así que contrasta siempre con el documento oficial. Las pruebas y criterios de alcance descritos son orientativos y deben adaptarse a cada aplicación y a su contexto; no sustituyen a una auditoría de tu entorno. Si quieres definir el alcance de una auditoría web o de API con las categorías de 2025, puedes hablar con el equipo de Hard2bit.