OWASP Top 10: qué es, cómo se elabora y cómo se aplica en seguridad web

Si trabajas en seguridad web, tarde o temprano alguien va a mencionar el OWASP Top 10. Es la lista de referencia que resume las diez categorías de riesgo más críticas en aplicaciones web, y la publica la Open Worldwide Application Security Project (OWASP), una fundación sin ánimo de lucro dedicada a mejorar la seguridad del software. La edición vigente es la de 2021, y su influencia va mucho más allá de un simple ranking: estándares como PCI DSS la citan, frameworks de desarrollo la integran en sus guías y los equipos de pentesting la usan como checklist de partida.

Esta lección recorre las diez categorías una por una, explica cómo OWASP las elige, qué cambió respecto a la versión anterior de 2017, y cómo puedes usar el Top 10 en la práctica, ya sea como pentester, como auditor o como desarrollador. Los laboratorios token-forge, path-read, orderkeak y profilepeek de whoami-labs cubren varios de los riesgos que aparecen aquí.

Todo lo que se explica en esta lección tiene fines educativos. Prueba las técnicas solo en entornos autorizados como los laboratorios de whoami-labs. Explotar vulnerabilidades en sistemas ajenos sin permiso es un delito.

Qué es OWASP#

OWASP (Open Worldwide Application Security Project) nació en 2001 como un proyecto comunitario y hoy es una fundación registrada en Estados Unidos con capítulos en más de 250 ciudades del mundo. No vende productos ni certifica herramientas: produce documentación, metodologías y software de código abierto. Entre sus proyectos más conocidos están el Top 10, el OWASP Testing Guide, el ASVS (Application Security Verification Standard), ZAP (Zed Attack Proxy) y el Dependency-Check.

El Top 10 no pretende ser una lista exhaustiva de todas las vulnerabilidades posibles. Es un documento de concienciación que destaca los riesgos más frecuentes y graves según datos reales de la industria. Su objetivo es que cualquier equipo, sin importar su madurez, tenga un punto de partida claro para priorizar esfuerzos.

Cómo se elabora el ranking#

El proceso combina datos cuantitativos y cualitativos:

• Datos de la industria. OWASP recopila conjuntos de datos de empresas de seguridad, bug bounties y organizaciones que analizan aplicaciones. Para la edición 2021, recibieron datos de más de 500.000 aplicaciones que cubrían más de 400 tipos de CWE (Common Weakness Enumeration). Ocho de las diez categorías se determinan directamente por estos datos, midiendo la incidencia (porcentaje de aplicaciones afectadas) y el impacto.
• Encuesta a la comunidad. Las dos categorías restantes se eligen mediante una encuesta a profesionales de seguridad. Esto permite captar tendencias emergentes que aún no aparecen en los datos porque son difíciles de detectar con herramientas automáticas. En 2021, las categorías elegidas por encuesta fueron A08 (fallos de integridad de software y datos) y A10 (SSRF).
• Agrupación por CWE. Cada categoría agrupa varios CWE relacionados. Por ejemplo, A03 (Injection) incluye CWE-79 (XSS), CWE-89 (SQL Injection) y CWE-77 (Command Injection), entre otros. Esto hace que las categorías sean más amplias que en ediciones anteriores.

Las diez categorías del Top 10 (2021)#

A01 — Broken Access Control#

Pasó del quinto puesto en 2017 al primero en 2021. Se encontró en el 94% de las aplicaciones analizadas. Incluye fallos como IDOR (acceso directo a objetos de otro usuario), escalada de privilegios, omisión de controles por manipulación de URL o parámetros, y CORS mal configurado. Los laboratorios profilepeek y path-read de whoami-labs practican esta categoría.

A02 — Cryptographic Failures#

Antes se llamaba «Sensitive Data Exposure» (A03 en 2017). El cambio de nombre refleja que el problema no es que los datos estén expuestos, sino que la criptografía que debería protegerlos falla: algoritmos obsoletos (MD5, SHA-1 para contraseñas), claves hardcodeadas, transmisión sin TLS, certificados no validados.

A03 — Injection#

Era el número uno en 2013 y 2017 y ahora baja al tercero. Agrupa SQL injection, NoSQL injection, command injection, LDAP injection y XSS (que en 2017 tenía su propia categoría A07). El laboratorio orderkeak practica inyección SQL avanzada en cláusulas ORDER BY.

A04 — Insecure Design#

Categoría nueva en 2021. Se refiere a fallos de diseño que no se pueden resolver con un parche de código: flujos de negocio que no validan límites, ausencia de rate limiting en funciones críticas, falta de defensa en profundidad. La diferencia con las demás categorías es que aquí el problema está en la arquitectura, no en la implementación.

A05 — Security Misconfiguration#

Sube desde el sexto puesto. Incluye cabeceras de seguridad ausentes, servicios innecesarios habilitados, credenciales por defecto, mensajes de error verbosos y permisos demasiado amplios en cloud. En 2021 absorbe también la antigua categoría de XXE (A04 en 2017), porque un parser XML mal configurado es, en esencia, una mala configuración.

A06 — Vulnerable and Outdated Components#

Antes A09. Usar bibliotecas, frameworks o dependencias con vulnerabilidades conocidas y no parcheadas. Es el riesgo más difícil de detectar con pruebas manuales: requiere un inventario de dependencias (SBOM) y herramientas como OWASP Dependency-Check o Snyk.

A07 — Identification and Authentication Failures#

Antes A02 (Broken Authentication). Baja de posición en parte porque la adopción de frameworks modernos de autenticación ha mejorado. Incluye credenciales débiles, falta de MFA, sesiones que no expiran, tokens predecibles y almacenamiento inseguro de contraseñas. El laboratorio token-forge practica manipulación de JWT y suplantación de identidad.

A08 — Software and Data Integrity Failures#

Categoría nueva, elegida por encuesta. Cubre fallos donde el software o los datos no se verifican antes de confiar en ellos: pipelines de CI/CD sin firma, actualizaciones automáticas sin validación de integridad, deserialización insegura (que en 2017 era A08). Un ejemplo clásico: un ataque a la cadena de suministro como el de SolarWinds (2020).

A09 — Security Logging and Monitoring Failures#

Antes A10. Subió un puesto porque sin logs adecuados, ninguna de las otras categorías se puede detectar a tiempo. Incluye ausencia de registros de autenticación, logs que no se monitorizan, alertas inexistentes ante patrones anómalos y falta de un plan de respuesta a incidentes.

A10 — Server-Side Request Forgery (SSRF)#

Categoría nueva, elegida por encuesta. El servidor realiza peticiones HTTP a destinos que el atacante controla a través de un parámetro: acceso a metadatos de cloud (169.254.169.254), escaneo de puertos internos, lectura de archivos vía esquemas como file://. Su relevancia creció mucho con la adopción masiva de arquitecturas cloud.

Evolución de 2017 a 2021#

Los cambios principales entre ambas ediciones son:

Más allá del Top 10 web#

OWASP no se limita a aplicaciones web clásicas. Tiene proyectos paralelos que adaptan el mismo enfoque a otros contextos:

OWASP ASVS#

El Application Security Verification Standard es un framework de requisitos de seguridad organizado en tres niveles (L1, L2, L3). Mientras el Top 10 es un documento de concienciación con diez categorías amplias, el ASVS contiene más de 280 requisitos verificables. Si el Top 10 dice «debes validar el control de acceso», el ASVS te dice exactamente qué comprobar, en qué capa y con qué evidencia. Es la referencia ideal para construir una checklist de auditoría detallada o un programa de desarrollo seguro.

OWASP Top 10 API Security (2023)#

Las APIs tienen un perfil de riesgo diferente al de una aplicación web con interfaz gráfica. El Top 10 de API destaca problemas como Broken Object Level Authorization (BOLA, equivalente a IDOR pero en contexto de API), Broken Authentication en flujos OAuth, Unrestricted Resource Consumption (ausencia de rate limiting), y Server Side Request Forgery. La edición 2023 (API:2023) actualizó la de 2019 incorporando los patrones de abuso más comunes en APIs REST y GraphQL.

OWASP Mobile Top 10 (2024)#

La edición 2024 del Mobile Top 10 actualiza la lista de riesgos en aplicaciones móviles. Incluye categorías como almacenamiento inseguro de datos en el dispositivo, comunicación insegura (certificados no fijados), autenticación y autorización débiles, manipulación de código (ingeniería inversa, tampering) y uso inadecuado de la plataforma (permisos excesivos, componentes exportados).

Cómo usar el Top 10 en un pentest#

Si estás realizando una auditoría de seguridad web, el Top 10 funciona como una lista de verificación inicial. No reemplaza una metodología completa como el OWASP Testing Guide (que tiene más de 90 pruebas individuales), pero te asegura que cubres lo más importante:

Checklist rápida de pentest web basada en OWASP Top 10

A01  ¿Puedo acceder a recursos de otro usuario cambiando IDs?
A01  ¿Puedo escalar de usuario normal a admin?
A02  ¿La aplicación transmite datos sensibles sin TLS?
A02  ¿Las contraseñas se almacenan con bcrypt/scrypt/argon2?
A03  ¿Los formularios y APIs son vulnerables a inyección SQL/XSS/command?
A04  ¿El flujo de negocio tiene validaciones del lado del servidor?
A05  ¿Hay cabeceras de seguridad (CSP, HSTS, X-Frame-Options)?
A05  ¿Existen servicios o puertos innecesarios expuestos?
A06  ¿Las dependencias tienen CVEs conocidos?
A07  ¿La autenticación exige MFA? ¿Las sesiones expiran?
A08  ¿El pipeline de CI/CD valida firmas e integridad?
A09  ¿Hay logs de autenticación y errores? ¿Se monitorizan?
A10  ¿La aplicación hace peticiones HTTP basadas en input del usuario?

En un pentest real, cada punto de esta lista se despliega en múltiples pruebas. Pero si solo tienes tiempo para una pasada rápida, esta checklist te garantiza que no te saltas nada crítico.

Cómo usar el Top 10 en desarrollo seguro#

Para un equipo de desarrollo, el Top 10 tiene tres usos principales:

• Formación. Es el documento de entrada para que cualquier desarrollador entienda los riesgos de seguridad web más frecuentes. Muchas empresas exigen que sus desarrolladores completen una formación basada en el Top 10 al menos una vez al año.
• Requisitos. Cada categoría del Top 10 se traduce en requisitos de implementación: usar consultas parametrizadas (A03), implementar RBAC del lado del servidor (A01), forzar TLS (A02). El ASVS los detalla.
• Code review. Durante la revisión de código, el Top 10 orienta qué buscar: llamadas a bases de datos sin parametrizar, comprobaciones de autorización que faltan, secretos hardcodeados, dependencias desactualizadas.

Relación con otros frameworks#

El OWASP Top 10 no existe en el vacío. Se complementa con otros estándares de seguridad:

Errores comunes#

• Tratar el Top 10 como una lista exhaustiva. Solo cubre las diez categorías de mayor riesgo. Vulnerabilidades como business logic flaws, race conditions o ataques de timing existen y no están en la lista.
• Confundir categorías con vulnerabilidades individuales. A03 Injection agrupa docenas de CWE diferentes. Que tu aplicación no tenga SQL injection no significa que esté libre de A03: puede tener XSS o command injection.
• Ignorar A04 Insecure Design. Es la categoría más difícil de abordar porque requiere cambios de arquitectura, no parches. Muchos equipos la pasan por alto y se centran solo en las vulnerabilidades de implementación.
• No actualizar la referencia. Algunos equipos siguen usando el Top 10 de 2013 o 2017. Las categorías cambian porque las amenazas cambian.
• Usar el Top 10 como única referencia de auditoría. Para una auditoría completa necesitas el OWASP Testing Guide o el ASVS. El Top 10 es un punto de partida, no un destino.

Preguntas frecuentes#

¿El OWASP Top 10 es obligatorio?#

No es un estándar de cumplimiento obligatorio por sí mismo, pero estándares como PCI DSS lo citan explícitamente. Si tu aplicación procesa pagos con tarjeta, abordar el Top 10 es un requisito formal.

¿Cuándo sale la próxima edición?#

OWASP no tiene un calendario fijo. La edición 2017 tardó cuatro años en actualizarse a la de 2021. Se espera una nueva versión cuando los datos muestren cambios significativos en el panorama de riesgos.

¿El Top 10 de API es lo mismo que el Top 10 web?#

No. Comparten el enfoque, pero las categorías son diferentes porque las APIs tienen un perfil de riesgo distinto. BOLA (Broken Object Level Authorization) es la número uno en API pero no aparece como tal en el Top 10 web.

¿Puedo certificarme en OWASP Top 10?#

OWASP no emite certificaciones. Existen certificaciones de terceros que cubren el Top 10 en su temario, como la eWPT de INE o la BSCP de PortSwigger.

¿XSS ya no es importante porque bajó de categoría?#

XSS sigue siendo una de las vulnerabilidades más encontradas. Solo se fusionó con la categoría de Injection (A03). De hecho, CWE-79 (XSS) fue el CWE más reportado dentro de A03 en los datos de 2021.

Resumen#

• OWASP es una fundación sin ánimo de lucro que produce documentación, metodologías y herramientas de código abierto para la seguridad del software.
• El Top 10 (2021) lista las diez categorías de riesgo más críticas en aplicaciones web, basándose en datos de más de 500.000 aplicaciones y una encuesta a profesionales.
• A01 Broken Access Control es ahora el riesgo número uno, desplazando a Injection (A03) que dominó las ediciones anteriores.
• Hay tres categorías nuevas respecto a 2017: Insecure Design (A04), Software and Data Integrity Failures (A08) y SSRF (A10).
• El Top 10 se complementa con el ASVS (requisitos detallados), el Testing Guide (metodología de pruebas) y las listas específicas para API (2023) y Mobile (2024).
• Úsalo como punto de partida para pentests, auditorías y formación de desarrolladores, pero no como lista exhaustiva.

Fuentes y lecturas recomendadas#

• OWASP Top 10 (2021)
• OWASP Top 10 API Security (2023)
• OWASP Mobile Top 10 (2024)
• OWASP ASVS
• OWASP Testing Guide
• CWE — Common Weakness Enumeration (MITRE)
• PCI DSS v4.0 — Requisito 6.2.4