El OWASP Top 10 es la referencia más citada en todo el sector de la ciberseguridad de aplicaciones web. Si desarrollas software, haces auditorías de seguridad o quieres iniciarte en el hacking web, entender esta lista te deja priorizar los riesgos que más explotan los atacantes reales. En esta guía repasamos las 10 categorías del OWASP Top 10:2025 (la edición vigente, publicada a principios de 2026) con ejemplos concretos y medidas de prevención.
¿Qué es OWASP y el OWASP Top 10?
OWASP (Open Worldwide Application Security Project) es una fundación sin ánimo de lucro que produce documentación, herramientas y estándares de seguridad de aplicaciones disponibles gratis para toda la comunidad. Su recurso de referencia es el OWASP Top 10: un documento de concienciación que recopila las diez categorías de riesgo más críticas para las aplicaciones web, elaborado a partir del análisis de datos reales de vulnerabilidades.
El Top 10 no es una norma técnica prescriptiva, es una guía de consenso de la industria. La edición 2025 es la octava iteración del proyecto y la primera en incorporar dos categorías completamente nuevas. Su contenido está publicado bajo licencia Creative Commons CC BY-SA 4.0, lo que permite su uso y adaptación con atribución.
¿Para qué sirve y a quién va dirigido?
El OWASP Top 10:2025 está dirigido a tres perfiles principales:
- Desarrolladores y equipos de ingeniería, que lo usan para integrar controles de seguridad desde el diseño y revisar el código frente a las vulnerabilidades más frecuentes.
- Pentesters y auditores de seguridad, que lo toman como marco de referencia para estructurar las pruebas en aplicaciones web y asegurarse de cubrir los vectores más explotados. Puedes profundizar en cada técnica en nuestra guía completa de hacking web.
- Responsables de seguridad y CISO, que lo usan para priorizar inversiones en controles y comunicar riesgos a la dirección con un lenguaje universalmente reconocido.
Muchos marcos regulatorios y estándares (PCI DSS, ISO 27001, NIST) recomiendan o referencian el OWASP Top 10 como punto de partida para la evaluación de riesgos en aplicaciones web.
OWASP Top 10:2025 — las 10 categorías explicadas
A continuación encontrarás cada categoría con su código oficial, una descripción, un ejemplo real y las principales medidas de prevención. Puedes consultar la documentación completa de cada una en owasp.org/Top10/2025/.
A01:2025 — Control de acceso roto (Broken Access Control)
Se produce cuando un sistema no aplica correctamente las restricciones sobre lo que un usuario autenticado puede hacer. Como indica OWASP: «Access control enforces policy such that users cannot act outside of their intended permissions.» En esta edición, la categoría absorbe también SSRF (CWE-918), antes una categoría independiente, porque el acceso no autorizado a recursos internos es en el fondo un problema de control de acceso.
Un ejemplo típico: un usuario normal modifica el parámetro ?user_id=123 por ?user_id=456 en una URL y accede al perfil de otro cliente sin ninguna restricción (IDOR). Puedes explorar este y otros vectores en el módulo de control de acceso e IDOR.
Para prevenirlo: aplica el principio de mínimo privilegio, deniega por defecto, valida permisos en el servidor en cada petición y usa controles de acceso a nivel de función y de objeto.
A02:2025 — Mala configuración de seguridad (Security Misconfiguration)
Sube del puesto #5 al #2 en esta edición, algo que refleja la creciente superficie de ataque de entornos cloud, contenedores y microservicios. Abarca permisos excesivos en servicios, puertos abiertos innecesarios, mensajes de error verbosos que revelan detalles del sistema y funciones activadas por defecto que nadie usa.
Por ejemplo: un servidor web expone la consola de administración de la base de datos en el puerto 8080 con credenciales por defecto (admin/admin). Un atacante la descubre con un escáner y vuelca toda la base de datos en minutos.
La prevención pasa por el hardening de sistemas, eliminar componentes y servicios que no hagan falta, deshabilitar mensajes de error detallados en producción y revisar configuraciones con herramientas como Burp Suite.
A03:2025 — Fallos en la cadena de suministro de software (Software Supply Chain Failures)
Esta categoría evoluciona desde «Vulnerable and Outdated Components» (A06:2021) para cubrir todo el ciclo de construcción y distribución de software. Tal como la define OWASP: «Software supply chain failures are breakdowns or other compromises in the process of building, distributing, or updating software.»
El ataque a SolarWinds (2020) es el ejemplo de libro: introdujo código malicioso en las actualizaciones legítimas del software de monitorización, infectando a unas 18.000 organizaciones que simplemente actualizaron el producto de un proveedor de confianza.
Para prevenirlo conviene mantener un inventario de dependencias (SBOM), monitorizar las bases de datos CVE/NVD, obtener componentes solo desde fuentes oficiales con canales seguros y endurecer los pipelines de CI/CD con autenticación de doble factor.
A04:2025 — Fallos criptográficos (Cryptographic Failures)
Antes se llamaba «Sensitive Data Exposure»; se renombró en 2021 para apuntar a la causa raíz, el uso de criptografía insuficiente o incorrecta para proteger datos en tránsito y en reposo. Baja del puesto #2 al #4.
Un caso habitual: una aplicación almacena contraseñas con MD5 sin sal. Cuando la base de datos se filtra, los hashes se rompen en pocas horas con tablas arcoíris, y quedan expuestas las cuentas de todos los usuarios.
Para prevenirlo: usa TLS 1.2+ para todos los datos en tránsito, cifra datos sensibles en reposo con algoritmos modernos (AES-256), aplica funciones de hash apropiadas para contraseñas (bcrypt, Argon2) y evita almacenar datos sensibles que no sean estrictamente necesarios.
A05:2025 — Inyección (Injection)
Fue la categoría número uno durante más de una década. Ahora baja al puesto #5, aunque sigue siendo muy prevalente. Ocurre cuando datos no validados se envían a un intérprete (base de datos, shell, LDAP) y se ejecutan como si fueran comandos o consultas. Incluye inyección SQL, XSS (Cross-Site Scripting), inyección de comandos y otras variantes.
Un ejemplo de SQLi: el campo de búsqueda de un e-commerce acepta la entrada ' OR '1'='1 y la concatena directamente en una consulta SQL, devolviendo todos los registros de la tabla de usuarios.
Se previene usando consultas parametrizadas o preparedStatements, validando y sanitizando todas las entradas, aplicando el principio de mínimo privilegio en cuentas de base de datos y añadiendo un WAF como capa adicional.
A06:2025 — Diseño inseguro (Insecure Design)
Introducida en 2021, esta categoría aborda los fallos que ya existen en la fase de diseño: la ausencia de modelado de amenazas, de patrones de diseño seguro y de controles de seguridad arquitectónicos. No es una mala implementación, es que la aplicación se diseñó sin tener en cuenta la seguridad desde el principio.
Un ejemplo claro: un sistema de recuperación de contraseña usa solo una pregunta secreta como única verificación. Un atacante conoce la respuesta (por redes sociales) y toma el control de la cuenta. El fallo no está en el código, está en que nadie modeló el riesgo de ese flujo.
La prevención pasa por integrar modelado de amenazas en la fase de diseño, usar patrones de diseño seguro, exigir revisiones de arquitectura y adoptar metodologías como STRIDE o DREAD desde el inicio del proyecto.
A07:2025 — Fallos de autenticación (Authentication Failures)
Se renombró en esta edición (antes «Identification and Authentication Failures») para ganar precisión. Mantiene el puesto #7. Ocurre cuando un sistema puede ser engañado para reconocer como legítimo a un usuario inválido. Incluye fallos de autenticación y gestión de sesiones.
Ejemplo: una aplicación no invalida la sesión tras el cierre de sesión. Un atacante obtiene el token de sesión de un ordenador compartido y sigue accediendo a la cuenta aunque el usuario ya haya cerrado sesión.
Prevenirlo implica implementar autenticación multifactor (MFA), validar contraseñas contra listas de credenciales comprometidas, limitar intentos de inicio de sesión, usar sesiones del lado del servidor con expiración y asegurar el flujo de recuperación de contraseña.
A08:2025 — Fallos de integridad en software o datos (Software or Data Integrity Failures)
Mantiene el puesto #8. Cubre situaciones en las que el código o los datos se asumen íntegros sin verificación: actualizaciones de software sin validar la firma digital, pipelines CI/CD con acceso no suficientemente protegido y deserialización insegura que permite la ejecución remota de código.
Ejemplo: un plugin de una aplicación se descarga desde una CDN de terceros sin verificar su hash. Un atacante comprometió la CDN y distribuyó una versión modificada con un troyano durante 48 horas antes de que alguien lo detectara.
Para prevenirlo: verifica las firmas digitales de las actualizaciones y dependencias, asegura los pipelines CI/CD, usa registros de paquetes privados y de confianza, y evita la deserialización de datos que vengan de fuentes no confiables.
A09:2025 — Fallos de registro y alertas de seguridad (Security Logging and Alerting Failures)
Mantiene el puesto #9 con un nombre actualizado (antes «Security Logging and Monitoring Failures»). El cambio pone el acento en la alerta: no basta con registrar eventos si no se generan alertas que activen una respuesta. Como señala OWASP: «Without logging and monitoring, attacks and breaches cannot be detected, and without alerting it is very difficult to respond quickly and effectively during a security incident.»
Ejemplo: un sistema registra los intentos fallidos de inicio de sesión en un archivo de log, pero nadie lo mira. Un atacante hace un ataque de credential stuffing de 50.000 intentos durante tres días sin que salte ninguna alerta.
Se previene centralizando los logs en un SIEM, definiendo umbrales de alerta para eventos críticos (múltiples fallos de autenticación, accesos fuera de horario), asegurando los propios logs frente a manipulación y revisando periódicamente que la cadena log, alerta, respuesta funciona de verdad.
A10:2025 — Manejo incorrecto de condiciones excepcionales (Mishandling of Exceptional Conditions)
Categoría completamente nueva en la edición 2025. Agrupa varios CWEs relacionados con el manejo deficiente de errores, situaciones inesperadas y condiciones de frontera. Según OWASP: «Mishandling exceptional conditions in software happens when programs fail to prevent, detect, and respond to unusual and unpredictable situations.»
Ejemplo: una aplicación de banca muestra el mensaje de error completo de la base de datos cuando una consulta falla, incluyendo el nombre de las tablas, el usuario de BD y la cadena de conexión. Un atacante usa esa información para construir un ataque de inyección SQL dirigido.
La prevención pasa por capturar las excepciones en su origen (y no únicamente en el nivel más alto), dar mensajes de error genéricos hacia el exterior, usar rollback en transacciones que fallen, aplicar limitación de tasa para evitar el agotamiento de recursos y registrar los errores completos solo en sistemas internos seguros.
¿Qué cambió respecto a 2021?
La edición 2025 del OWASP Top 10 trae cambios significativos respecto a la de 2021. Las dos novedades más importantes son la incorporación de Software Supply Chain Failures como categoría propia (que expande la anterior «Vulnerable and Outdated Components» para cubrir todo el ciclo de vida del software) y la entrada de Mishandling of Exceptional Conditions, una categoría elegida por la comunidad para abordar el manejo deficiente de errores, algo que no tenía representación específica en la lista anterior.
También la antigua A10:2021 (SSRF) ya no existe como categoría independiente: sus riesgos se han fusionado en A01:2025 (Broken Access Control), donde quedan explícitamente recogidos bajo el CWE-918.
| Código 2025 | Nombre 2025 | Descripción breve | Relación con 2021 |
|---|---|---|---|
| A01:2025 | Broken Access Control | Acceso fuera de permisos; incluye IDOR, CORS y ahora SSRF | A01:2021 (mismo puesto; absorbe A10:2021 SSRF) |
| A02:2025 | Security Misconfiguration | Configuraciones inseguras, puertos abiertos, errores verbosos | A05:2021 (sube de #5 a #2) |
| A03:2025 | Software Supply Chain Failures | Dependencias comprometidas, builds manipulados, paquetes maliciosos | A06:2021 «Vulnerable and Outdated Components» (expandido) |
| A04:2025 | Cryptographic Failures | Cifrado ausente o débil en datos en tránsito y en reposo | A02:2021 (baja de #2 a #4) |
| A05:2025 | Injection | SQLi, XSS, inyección de comandos por falta de validación | A03:2021 (baja de #3 a #5) |
| A06:2025 | Insecure Design | Ausencia de controles de seguridad en la fase de diseño | A04:2021 (baja de #4 a #6) |
| A07:2025 | Authentication Failures | Contraseñas débiles, sesiones mal gestionadas, falta de MFA | A07:2021 «Identification and Authentication Failures» (mismo puesto) |
| A08:2025 | Software or Data Integrity Failures | Actualizaciones sin verificar firma, deserialización insegura | A08:2021 (mismo puesto) |
| A09:2025 | Security Logging and Alerting Failures | Sin logs ni alertas que permitan detectar y responder a ataques | A09:2021 «Security Logging and Monitoring Failures» (mismo puesto) |
| A10:2025 | Mishandling of Exceptional Conditions | Manejo deficiente de errores: mensajes verbosos, DoS, fallo en rollback | NUEVA (A10:2021 SSRF fue fusionada en A01:2025) |
Cómo usar el OWASP Top 10 en pentesting y desarrollo seguro
El OWASP Top 10 es un punto de partida, no un checklist exhaustivo. En pentesting sirve para asegurarte de que el alcance de una auditoría de aplicaciones web cubre al menos los vectores más prevalentes. Puedes estructurar tus pruebas con herramientas como Burp Suite y atacar cada categoría de forma sistemática: inyecciones con el escáner activo, control de acceso probando con roles distintos, fallos criptográficos analizando las cabeceras y la configuración TLS.
En desarrollo seguro, el Top 10 se convierte en una lista de comprobación de arquitectura y revisión de código. Hay tres momentos en los que aplicarlo: en el diseño, modelando amenazas considerando A06 (Insecure Design) y A01 (Broken Access Control) antes de escribir una línea de código; en la implementación, usando consultas parametrizadas (A05), cifrado adecuado (A04) y autenticación robusta con MFA (A07); y en la operación, monitorizando logs y configurando alertas (A09), gestionando dependencias y actualizaciones (A03) y respondiendo a errores de forma segura (A10).
Para ir más allá del Top 10, OWASP ofrece otras guías complementarias: la WSTG (Web Security Testing Guide) para metodología de pruebas detallada, y el ASVS (Application Security Verification Standard) para requisitos de seguridad verificables por nivel de madurez. El Top 10 es el punto de entrada; WSTG y ASVS son el estándar profesional. Nuestro curso de hacking web cubre en profundidad las categorías más explotadas: inyección SQL, XSS, CSRF y SSRF, autenticación y sesiones, control de acceso e IDOR y subida de archivos y RCE.
Preguntas frecuentes
¿Qué es OWASP?
OWASP (Open Worldwide Application Security Project) es una fundación internacional sin ánimo de lucro dedicada a mejorar la seguridad del software. Produce documentación, herramientas, marcos y comunidades de forma abierta y gratuita. Entre sus proyectos más conocidos están el OWASP Top 10, la WSTG, el ASVS, Juice Shop (aplicación web vulnerable para practicar) y ZAP (escáner de seguridad web de código abierto). Todo su contenido se publica bajo licencias abiertas y puede consultarse en owasp.org.
¿Cada cuánto se actualiza el OWASP Top 10?
No hay un ciclo fijo, pero la frecuencia habitual ha sido cada tres o cuatro años: ediciones en 2003, 2004, 2007, 2010, 2013, 2017, 2021 y 2025. Cada nueva versión se basa en datos recopilados de la industria (miles de aplicaciones analizadas, contribuciones de empresas de seguridad) y en una encuesta a la comunidad para identificar categorías emergentes. La edición 2025 es la octava de la historia del proyecto.
¿Es el OWASP Top 10 una norma obligatoria?
No directamente. El OWASP Top 10 es un documento de concienciación, no una norma técnica de cumplimiento obligatorio por sí misma. Aun así, estándares y regulaciones como PCI DSS (para procesamiento de pagos), marcos de referencia de la industria y muchos pliegos de contratación pública o privada lo referencian explícitamente como requisito mínimo de auditoría de seguridad de aplicaciones. En la práctica, cubrir el Top 10 se ha convertido en la línea de base que cualquier aplicación web debería superar.
¿Cuál es la diferencia entre el Top 10, la WSTG y el ASVS?
Son tres herramientas complementarias con propósitos distintos. El OWASP Top 10 es una lista de concienciación de los riesgos más críticos, útil para priorizar y comunicar. La WSTG (Web Security Testing Guide) es una metodología de pruebas detallada con técnicas y casos de prueba específicos, pensada para pentesters que necesitan un procedimiento paso a paso. El ASVS (Application Security Verification Standard) define niveles de seguridad (L1, L2, L3) con requisitos verificables, para equipos de desarrollo que quieren certificar el nivel de madurez de seguridad de su aplicación. El Top 10 te dice qué mirar; la WSTG, cómo probarlo; el ASVS, qué requisito concreto debe cumplir la aplicación.
¿Cómo empiezo a proteger mi aplicación con el OWASP Top 10?
El punto de partida más práctico es hacer un mapeo rápido: revisa cada una de las 10 categorías y evalúa si tu aplicación tiene controles para cada una. Para A01, ¿compruebas permisos en el servidor en cada petición? Para A05, ¿usas consultas parametrizadas en todos los accesos a la base de datos? Para A07, ¿tienes MFA disponible? A partir de ahí, prioriza por impacto potencial en tu contexto. Si quieres hacerlo de forma práctica, nuestro curso de hacking web te enseña a atacar y defender cada categoría con laboratorios reales.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»¿Qué es OWASP?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»OWASP (Open Worldwide Application Security Project) es una fundación internacional sin ánimo de lucro dedicada a mejorar la seguridad del software. Produce documentación, herramientas y comunidades de forma abierta y gratuita. Entre sus proyectos están el OWASP Top 10, la WSTG, el ASVS, Juice Shop y ZAP.»}},{«@type»:»Question»,»name»:»¿Cada cuánto se actualiza el OWASP Top 10?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»No existe un ciclo fijo, pero la frecuencia habitual ha sido cada tres o cuatro años: 2003, 2004, 2007, 2010, 2013, 2017, 2021 y 2025. Cada versión se basa en datos de la industria y en una encuesta a la comunidad. La edición 2025 es la octava del proyecto.»}},{«@type»:»Question»,»name»:»¿Es el OWASP Top 10 una norma obligatoria?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»No directamente. Es un documento de concienciación, no una norma técnica de cumplimiento obligatorio por sí misma. Aun así, estándares como PCI DSS y muchos pliegos de contratación lo referencian como requisito mínimo de auditoría de seguridad de aplicaciones web.»}},{«@type»:»Question»,»name»:»¿Cuál es la diferencia entre el Top 10, la WSTG y el ASVS?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»El OWASP Top 10 es una lista de concienciación de los riesgos más críticos. La WSTG (Web Security Testing Guide) es una metodología de pruebas detallada para pentesters. El ASVS (Application Security Verification Standard) define niveles de seguridad con requisitos verificables para equipos de desarrollo. El Top 10 te dice qué mirar; la WSTG, cómo probarlo; el ASVS, qué requisito cumplir.»}},{«@type»:»Question»,»name»:»¿Cómo empiezo a proteger mi aplicación con el OWASP Top 10?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Haz un mapeo rápido: revisa cada una de las 10 categorías y evalúa si tu aplicación tiene controles para cada una (permisos en el servidor para A01, consultas parametrizadas para A05, MFA para A07…). A partir de ahí, prioriza por impacto potencial en tu contexto.»}}]}
