El OWASP Top 10 es el listado de referencia mundial sobre las vulnerabilidades más críticas en aplicaciones web. Lo publica la Open Web Application Security Project (OWASP), una fundación sin ánimo de lucro dedicada a mejorar la seguridad del software. En este artículo recorremos las diez categorías de la edición vigente, para que sepas qué buscar, cómo prevenirlas y por qué aparecen una y otra vez en cualquier pentest.

Qué es y cómo se elabora el OWASP Top 10

OWASP publica cada pocos años un Top 10 basado en datos reales aportados por empresas de seguridad y en una encuesta a la comunidad. No es un estándar certificable, pero es el marco de referencia que la mayoría de auditorías y equipos de desarrollo usan para hablar el mismo idioma cuando tratan riesgos en web.

Las categorías agrupan familias de vulnerabilidades más que fallos concretos. Por eso una misma aplicación puede tener varios problemas que caen en la misma categoría, o uno solo que afecta a varias a la vez.

A01: Broken Access Control

El control de acceso determina qué puede hacer cada usuario una vez autenticado. Cuando falla, usuarios normales acceden a funciones de administración, a datos de otros usuarios o a recursos que no les corresponden. Casos típicos: manipular un ID en la URL para ver registros ajenos (IDOR), invocar endpoints de admin desde un rol básico o escalar privilegios mediante parámetros ocultos.

Prevención: aplicar control de acceso en el servidor (nunca en el cliente), denegar por defecto, auditar los cambios y usar frameworks que lo gestionen de forma centralizada.

A02: Cryptographic Failures

Incluye todo lo que tiene que ver con una mala gestión del cifrado: transmitir credenciales o datos sensibles por HTTP plano, usar algoritmos obsoletos (MD5, SHA1, DES), almacenar contraseñas sin hash robusto, reutilizar claves, no rotar certificados o no proteger los secretos.

Prevención: cifrado en tránsito con TLS 1.2+ obligatorio, contraseñas con Argon2/bcrypt, cifrado en reposo donde corresponda y gestión de secretos con KMS o vaults, no en variables de entorno en texto plano.

A03: Injection

Inyección SQL, NoSQL, LDAP, de comandos, de cabeceras... Todas comparten el mismo patrón: entrada del usuario que acaba interpretada como código. Sigue siendo una de las categorías más explotadas, especialmente por la proliferación de nuevos lenguajes de consulta en bases de datos NoSQL y ORM mal usados.

Prevención: consultas parametrizadas, ORM con bind de parámetros, validación estricta del lado servidor, allowlists en lugar de blocklists y ejecución con el mínimo privilegio necesario.

A04: Insecure Design

Fallos conceptuales en el diseño de la aplicación: ausencia de límites de tasa en endpoints sensibles, falta de verificación en flujos de recuperación de contraseña, funcionalidades que permiten enumerar usuarios... No son bugs que se arreglen con un parche, sino decisiones arquitectónicas erróneas.

Prevención: amenazas modeladas (threat modeling) en fase de diseño, historias de abuso junto a las de usuario y patrones de diseño seguros desde el inicio del proyecto.

A05: Security Misconfiguration

Configuraciones por defecto que nunca se endurecieron, cabeceras de seguridad ausentes, directorios de administración accesibles, mensajes de error que revelan detalles del stack, buckets en la nube abiertos al público... Representa una proporción altísima de los incidentes reales por su facilidad de explotación.

Prevención: hardening automatizado, infraestructura como código revisada, escaneos de configuración continuos y bastionado específico para entornos cloud.

A06: Vulnerable and Outdated Components

Usar librerías, frameworks o dependencias con vulnerabilidades conocidas. Un solo paquete obsoleto puede exponer toda la aplicación. La cadena de suministro software (SBOM) es hoy un vector de ataque común: basta con comprometer una dependencia para infectar miles de proyectos.

Prevención: inventario de dependencias (SBOM), escáneres automáticos en CI (Snyk, Dependabot, Trivy), actualizaciones periódicas y política clara de respuesta cuando sale un CVE.

Las vulnerabilidades de componentes de terceros son probablemente las más frecuentes en pentests de aplicaciones en producción. No por mala intención del equipo, sino porque no existe un proceso continuo de actualización.

A07: Identification and Authentication Failures

Problemas en cómo se identifica a los usuarios: contraseñas débiles permitidas, falta de MFA, sesiones que no expiran, tokens predecibles, login sin bloqueo tras intentos fallidos, recuperación de contraseña con preguntas triviales. Son la puerta de entrada habitual a los incidentes de suplantación de identidad.

Prevención: MFA obligatorio en accesos privilegiados, política de contraseñas basada en NIST, gestión correcta del ciclo de vida de sesiones y tokens, y rate limiting en los endpoints de autenticación.

A08: Software and Data Integrity Failures

Fallos que permiten introducir cambios no autorizados en el código o los datos: actualizaciones sin firma digital, pipelines de CI/CD sin control de integridad, dependencias descargadas desde fuentes no verificadas, deserialización insegura de objetos. Incidentes como SolarWinds popularizaron esta categoría.

Prevención: firma digital de artefactos, verificación de integridad en los despliegues, segmentación estricta en los pipelines y validación de objetos al deserializar.

A09: Security Logging and Monitoring Failures

Sin logs adecuados, un ataque puede durar meses sin ser detectado. Esta categoría cubre la falta de registro de eventos críticos, logs que no se centralizan, ausencia de alertas ante comportamientos anómalos y carencia de procedimientos de respuesta ante incidentes.

Prevención: logging estructurado de eventos críticos, envío a un SIEM, alertas automáticas sobre patrones anómalos y un plan de respuesta con roles claros.

A10: Server-Side Request Forgery (SSRF)

La aplicación hace peticiones HTTP en nombre del usuario hacia URLs que éste puede controlar. El atacante lo usa para acceder a recursos internos (metadata de cloud, servicios intranet) que no están expuestos al exterior. Con la extensión del cloud, SSRF se ha convertido en una vía frecuente de escalado en entornos modernos.

Prevención: allowlist de dominios y protocolos permitidos, segmentación de red que impida alcanzar metadata services, bloqueo de rangos RFC1918 y validación estricta de URLs de destino.

Cómo aplicar el OWASP Top 10 en la práctica

Tener el Top 10 como referencia no es lo mismo que estar cubierto frente a él. Recomendamos estos pasos para cualquier equipo:

  • Revisar el código y la arquitectura frente a cada categoría, al menos una vez al año
  • Incluir chequeos automáticos en el pipeline de CI (SAST, SCA, DAST)
  • Integrar el OWASP Top 10 en la formación de desarrolladores y QA
  • Hacer pentests periódicos centrados explícitamente en estas categorías
  • Para entornos certificados en ISO 27001 o adecuados al ENS, documentar los controles como evidencia

¿Quieres una auditoría OWASP de tu aplicación web?

Realizamos pentests de aplicación web alineados con OWASP, con entregable para equipo técnico y dirección. Primera consulta gratuita para definir alcance y presupuesto.

Solicitar consulta gratuita →