Ilustración de una aplicación web con diez capas de seguridad numeradas y fragmentos de código

OWASP Top 10:2025: los fallos web más graves y cómo corregirlos en el código

El OWASP Top 10:2025, la lista de referencia de los riesgos más graves en aplicaciones web, sigue encabezada por el control de acceso roto e incorpora dos categorías nuevas: los fallos en la cadena de suministro de software y la mala gestión de condiciones excepcionales. Una guía publicada el 29/10/2026 por Steven Richards, especialista en seguridad de la consultora Veduis, repasa cada categoría con ejemplos de código vulnerable y su corrección, y sirve para entender por qué la lista ha cambiado respecto a la edición de 2021.

Las claves del OWASP Top 10:2025 para desarrolladores web en 30 segundos

  • El control de acceso roto sigue en el primer puesto y ahora absorbe la falsificación de peticiones del lado del servidor (SSRF).
  • La mala configuración sube del quinto al segundo lugar; la inyección baja del tercero al quinto.
  • Son nuevas las categorías de cadena de suministro de software y de manejo incorrecto de condiciones excepcionales, que incluye fallar en abierto.
  • OWASP basa la lista en datos de más de 2,8 millones de aplicaciones y en una encuesta a la comunidad, que eligió dos de las diez categorías.

OWASP (Open Worldwide Application Security Project) es una fundación sin ánimo de lucro que publica guías abiertas de seguridad. Su Top 10 no es una norma, pero se usa como referencia mínima en auditorías y en la formación de desarrolladores. Según la introducción oficial de la edición 2025, ocho categorías salen del análisis de datos donados por colaboradores y las otras dos se eligieron en una encuesta a la comunidad. El análisis cubrió 589 tipos de debilidades CWE (Common Weakness Enumeration), de las que 248 quedan repartidas entre las diez categorías.

La guía de Veduis parte de una idea que repite en todo el texto: cada vulnerabilidad suele nacer de una decisión de diseño que parecía razonable y que deja abierta una frontera de confianza. Por eso acompaña cada categoría con un fragmento de código vulnerable, sobre todo en Node.js y Express, y la versión corregida.

Qué ha cambiado respecto a 2021

El orden de la edición 2025 queda así:

  • A01: Control de acceso roto (Broken Access Control).
  • A02: Configuración de seguridad incorrecta (Security Misconfiguration).
  • A03: Fallos en la cadena de suministro de software (Software Supply Chain Failures).
  • A04: Fallos criptográficos (Cryptographic Failures).
  • A05: Inyección (Injection).
  • A06: Diseño inseguro (Insecure Design).
  • A07: Fallos de autenticación (Authentication Failures).
  • A08: Fallos de integridad de software o datos (Software or Data Integrity Failures).
  • A09: Fallos de registro y alertas de seguridad (Security Logging & Alerting Failures).
  • A10: Manejo incorrecto de condiciones excepcionales (Mishandling of Exceptional Conditions).

OWASP explica que A03 amplía la antigua categoría de componentes vulnerables y desactualizados para incluir los compromisos en sistemas de compilación e infraestructuras de distribución, y que fue la preocupación más votada en la encuesta. A10 es la gran novedad: agrupa 24 CWE relacionadas con errores lógicos, gestión deficiente de errores y sistemas que fallan en abierto. La SSRF, que en 2021 tenía categoría propia, pasa a formar parte de A01, y A07 y A09 cambian de nombre sin moverse de puesto.

La lista de aplicaciones web convive con otras específicas, como el OWASP Top 10 para aplicaciones con IA que opensecurity analizó en octubre.

Los errores de código que más se repiten

En control de acceso, Richards pone el ejemplo clásico de referencia directa insegura a objetos (IDOR): un punto de la API que devuelve un registro por su identificador sin comprobar que pertenece al usuario que lo pide. La corrección que propone es filtrar por propietario o por cliente en la propia consulta a la base de datos, en lugar de confiar en que la interfaz no muestre el enlace. Para la SSRF recomienda analizar la URL, permitir solo destinos HTTPS de una lista cerrada, resolver el DNS y bloquear rangos privados y de bucle local.

En configuración, la guía desaconseja devolver trazas de error al cliente y sugiere responder con una referencia genérica y guardar el detalle en los registros internos, además de cabeceras como la política de seguridad de contenidos (CSP) y HSTS mediante el middleware helmet. En la cadena de suministro recomienda instalar con npm ci y archivo de bloqueo, usar npm audit --audit-level=high como filtro en la integración continua, generar listas de materiales de software (SBOM) con Syft o CycloneDX y aislar las credenciales de compilación. Casos recientes como el malware colado en copias de Rank Math SEO PRO muestran que el riesgo no es teórico.

En criptografía, el texto desaconseja guardar contraseñas con MD5, SHA-1 o SHA-256 sin sal y generar tokens con Math.random(); propone bcrypt con factor de coste 12 y crypto.randomBytes(32). Para la inyección, la receta sigue siendo la consulta parametrizada y, frente al XSS, usar textContent para texto plano y DOMPurify cuando haya que admitir HTML.

Diseño, autenticación y fallos que dejan la puerta abierta

El apartado de diseño inseguro usa el ejemplo de un código de verificación de seis cifras: solo hay un millón de combinaciones, así que sin límite de intentos puede probarse entero. La guía propone limitar peticiones, dar a los códigos una vida de cinco a diez minutos, invalidarlos tras cinco fallos y avisar por correo de cualquier cambio de credenciales. En autenticación recuerda regenerar el identificador de sesión tras el inicio de sesión para evitar la fijación de sesión, y apuesta por llaves de acceso (passkeys) y doble factor.

Para A08 recomienda la integridad de subrecursos (SRI) en los scripts de terceros y evitar la deserialización insegura, sustituyéndola por JSON validado con esquemas. En registros, la propuesta es guardar inicios de sesión correctos y fallidos, cambios de contraseña, denegaciones de acceso y concesiones de privilegios, y alertar, por ejemplo, cuando una misma IP acumule más de diez rechazos de autorización en cinco minutos, un umbral que la guía plantea como orientación.

El ejemplo de A10 resume bien por qué la categoría es nueva: un bloque catch que, cuando el servicio de autorización no responde a tiempo, deja pasar la petición. La recomendación es fallar en cerrado en cualquier comprobación que no pueda confirmar la identidad o los permisos. El artículo incluye algunas cifras generales, como el tiempo medio que tarda en detectarse una intrusión, que no acompaña de una fuente concreta.

Preguntas frecuentes

¿Qué es el OWASP Top 10?

Es la lista de riesgos de seguridad más críticos en aplicaciones web que publica la fundación OWASP. Se usa como referencia mínima en desarrollo seguro y auditorías.

¿Qué categorías son nuevas en el OWASP Top 10:2025?

Fallos en la cadena de suministro de software (A03), que amplía la antigua de componentes vulnerables, y manejo incorrecto de condiciones excepcionales (A10).

¿Dónde está la SSRF en la edición 2025?

OWASP la ha integrado en A01, control de acceso roto, que sigue en el primer puesto.

¿Cómo se elaboró la lista de 2025?

Ocho categorías salen de datos de más de 2,8 millones de aplicaciones y dos de una encuesta a la comunidad de seguridad.

Fuentes:

Scroll al inicio