OWASP Top 10:2025:

la lista que todo desarrollador debería memorizar

Privacidad y seguridad web  |  unfantasmaenelsistema.com

Si trabajas escribiendo, auditando o asegurando aplicaciones web, hay una lista que probablemente hayas visto citada cientos de veces: el OWASP Top 10. Es la clasificación de los riesgos de seguridad más críticos en aplicaciones web, elaborada por el Open Worldwide Application Security Project (OWASP), una fundación sin ánimo de lucro que lleva más de veinte años marcando el estándar de facto en seguridad de software.

En noviembre de 2025 OWASP presentó en el AppSec Global de Washington D.C. la primera revisión completa de la lista desde 2021, finalizada oficialmente en enero de 2026. No es un simple lavado de cara: entran dos categorías completamente nuevas, la inyección baja del primer al quinto puesto por primera vez en la historia de la lista, y el clásico SSRF desaparece como categoría propia para fundirse dentro de otra. En este artículo repasamos las diez categorías de la edición 2025 con ejemplos reales, qué ha cambiado respecto a 2021 y cómo debe usarse esta lista según seas desarrollador, auditor o responsable de seguridad.

1. Qué es OWASP y por qué su Top 10 importa

OWASP no certifica productos ni vende nada: es una comunidad abierta que documenta, de forma gratuita, el conocimiento colectivo de miles de profesionales de seguridad de aplicaciones. El Top 10 es su proyecto más conocido, pero la fundación mantiene decenas de guías de referencia —el OWASP Application Security Verification Standard (ASVS), el OWASP Testing Guide, o Juice Shop, su aplicación deliberadamente vulnerable para practicar— que profundizan en cada uno de estos riesgos.

El Top 10 importa porque se ha convertido en el lenguaje común de la industria: aparece citado en normativas (PCI DSS lo referencia explícitamente), en pliegos de auditoría, en herramientas de análisis estático y dinámico, y en prácticamente cualquier certificación de seguridad web. Cuando un auditor te dice que encontró un «A01» en tu aplicación, tanto tú como él sabéis exactamente de qué universo de problemas está hablando sin necesidad de explicaciones adicionales.

1.1 Cómo se elabora la lista

La metodología combina dos fuentes. Por un lado, datos de más de 590.000 aplicaciones analizadas por herramientas de terceros (escáneres SAST, DAST y proveedores de bug bounty), que aportan la prevalencia real de cada tipo de vulnerabilidad. Por otro, una encuesta a cientos de profesionales de seguridad de todo el mundo, que aporta la severidad percibida y detecta riesgos emergentes que los datos históricos todavía no reflejan bien —como ocurrió con los fallos de cadena de suministro, que entran directamente como categoría nueva en 2025 pese a no tener aún el volumen de datos históricos de otras categorías más veteranas.

2. Las 10 categorías de OWASP Top 10:2025

A continuación, cada categoría con su definición oficial, un ejemplo realista y la forma más directa de mitigarla.

2.1 A01: Broken Access Control (Control de acceso roto)

Repite en el primer puesto, como ya ocurría en 2021. Ocurre cuando una aplicación no verifica correctamente que un usuario tenga permiso para hacer lo que está intentando hacer. El ejemplo clásico es el IDOR (Insecure Direct Object Reference): cambiar un identificador en la URL y acceder a datos de otro usuario.

# El usuario 1042 solicita su propia factura, con normalidad:
GET /api/facturas/1042
 
# Pero nada impide que pruebe con el ID de otro usuario...
GET /api/facturas/1043
# ...y si el backend no valida que la factura 1043 pertenece
# al usuario autenticado, se la sirve igualmente.

En la edición 2025, el antiguo SSRF (Server-Side Request Forgery) —que en 2021 era la categoría A10 independiente— se ha integrado dentro de A01, al considerarse fundamentalmente un fallo de control de acceso: el servidor realiza una petición a un recurso que el atacante no debería poder alcanzar.

2.2 A02: Security Misconfiguration (Configuración de seguridad incorrecta)

Sube del quinto al segundo puesto, uno de los movimientos más llamativos de la revisión 2025. Cubre desde paneles de administración expuestos con credenciales por defecto, hasta buckets de almacenamiento en la nube abiertos al público, mensajes de error que revelan trazas completas de pila, o cabeceras de seguridad ausentes. El auge de la infraestructura como código y los despliegues en la nube ha multiplicado las superficies donde un solo parámetro mal puesto expone datos.

2.3 A03: Software Supply Chain Failures (Fallos de cadena de suministro) — NUEVA

Categoría completamente nueva en 2025. Absorbe buena parte de lo que en 2021 era A06: Vulnerable and Outdated Components, pero amplía el foco: no es solo usar una librería con una CVE conocida, sino cualquier compromiso en el proceso de construir, distribuir o actualizar software — un pipeline de CI/CD comprometido, un paquete de npm o PyPI con una versión maliciosa publicada por un atacante que robó las credenciales del mantenedor, o una imagen de contenedor base contaminada.

2.4 A04: Cryptographic Failures (Fallos criptográficos)

Datos sensibles transmitidos o almacenados sin cifrar, algoritmos obsoletos (MD5 o SHA-1 para contraseñas), claves hardcodeadas en el código fuente, o certificados TLS mal validados. La recomendación de fondo no ha cambiado desde 2021: cifra en tránsito y en reposo, usa algoritmos modernos (bcrypt, argon2 para contraseñas; TLS 1.3 para tránsito) y nunca inventes tu propio esquema criptográfico.

2.5 A05: Injection (Inyección)

La categoría más veterana del Top 10 —inyección SQL, NoSQL, de comandos del sistema operativo, LDAP— cae del primer al quinto puesto, no porque haya dejado de ser peligrosa, sino porque las herramientas modernas (ORMs con parametrización por defecto, frameworks que escapan variables automáticamente) han reducido su prevalencia media. Sigue siendo, dos décadas después, la causa de algunas de las brechas más sonadas.

# Vulnerable: concatenacion directa del input del usuario
query = "SELECT * FROM usuarios WHERE email = '" + email_input + "'"
 
# Un atacante envia como email:  ' OR '1'='1
# La consulta resultante devuelve TODOS los usuarios
 
# Correcto: consulta parametrizada, el driver escapa el valor
cursor.execute("SELECT * FROM usuarios WHERE email = %s", (email_input,))

2.6 A06: Insecure Design (Diseño inseguro)

No es un bug de implementación, es un fallo de arquitectura: un flujo de recuperación de contraseña que no expira los tokens, una lógica de negocio que permite aplicar un descuento infinitas veces, o la ausencia total de modelado de amenazas antes de construir una funcionalidad crítica. Esta categoría no se arregla con un parche; se arregla rediseñando, por eso OWASP insiste en incorporar seguridad desde la fase de diseño («shift left»), no al final.

2.7 A07: Authentication Failures (Fallos de autenticación)

Antes llamada «Identification and Authentication Failures». Cubre desde permitir contraseñas débiles o credential stuffing sin límite de intentos, hasta sesiones que no expiran nunca o IDs de sesión predecibles. La mitigación más efectiva sigue siendo la misma de siempre: autenticación multifactor, límites de intentos con bloqueo progresivo, y rotación de identificadores de sesión tras cada inicio de sesión.

2.8 A08: Software or Data Integrity Failures (Fallos de integridad)

Código o datos que se aceptan sin verificar su integridad: actualizaciones de software sin firmar, deserialización insegura de datos que no son de confianza, o pipelines de CI/CD sin controles de acceso que permiten a cualquiera con acceso al repositorio inyectar código en el artefacto final que se despliega a producción.

2.9 A09: Security Logging & Alerting Failures (Fallos de registro y alertas)

Sin logs, sin alertas y sin monitorización en tiempo real, una brecha puede pasar meses sin detectarse —el tiempo medio de detección de una intrusión sigue midiéndose en semanas en buena parte de las organizaciones. Si ya conoces la fase de detección desde el otro lado, en nuestro artículo sobre Volatility 3 y en la introducción al SOC tratamos justo la parte de respuesta que empieza cuando esta categoría falla.

2.10 A10: Mishandling of Exceptional Conditions (Manejo incorrecto de errores) — NUEVA

La segunda categoría nueva de 2025. Agrupa 24 CWEs distintos en torno a un mismo patrón: qué hace la aplicación cuando algo sale mal. Errores no capturados que tumban el servicio, lógica de «fail open» que concede acceso por defecto cuando un servicio de verificación no responde, o condiciones límite (valores nulos, desbordamientos, timeouts) que el desarrollador nunca contempló. Es, en cierto modo, el reconocimiento de que gran parte de los fallos de seguridad reales no ocurren en el camino feliz del código, sino en sus bordes.

3. Qué ha cambiado respecto a 2021

El titular de esta edición es sencillo: el control de acceso y la configuración concentran ahora la mayoría de los incidentes reales, por delante de la inyección, que durante quince años fue sinónimo del propio Top 10.

4. Cómo usar el Top 10 en la práctica

4.1 Si eres desarrollador

Úsalo como checklist de revisión de código, no como lista a memorizar de memoria antes de un examen. Cada categoría tiene, dentro de la documentación oficial de owasp.org, una sección de «Cómo prevenirlo» con recomendaciones accionables por lenguaje y framework.

4.2 Si haces auditorías o pentesting

El Top 10 es el punto de partida, nunca el punto de llegada: cubre los riesgos más *comunes*, no todos los riesgos *posibles* de una aplicación concreta. Herramientas como Burp Suite, que ya cubrimos en detalle en este blog, están construidas precisamente para detectar de forma sistemática buena parte de estas diez categorías durante una auditoría manual.

Conclusión

El OWASP Top 10:2025 no es una lista para memorizar de carrerilla, es un mapa de dónde está fallando realmente la industria del software en este momento. Que la configuración incorrecta haya escalado hasta el segundo puesto y que aparezcan dos categorías completamente nuevas —cadena de suministro y manejo de errores— dice mucho de hacia dónde se ha movido la superficie de ataque real: menos hacia el código de la propia aplicación, y más hacia todo lo que la rodea y la construye.

La forma más eficaz de interiorizar estas diez categorías no es leerlas, es verlas fallar en un entorno controlado. Si quieres practicar cada una con ejemplos reales explotables, OWASP Juice Shop y los laboratorios de PortSwigger Web Security Academy son gratuitos y están diseñados exactamente para eso.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)