BLURTEK Academy · Guía técnica
OWASP Top 10 explicado con ejemplos
Recorrido práctico por las diez categorías del OWASP Top 10 (2021), cada una con un ejemplo concreto y su mitigación.
El OWASP Top 10 es la lista de referencia sobre los riesgos de seguridad más críticos en aplicaciones web. La edición vigente es la de 2021, construida a partir de datos de cientos de miles de aplicaciones. No es un estándar de cumplimiento, sino un punto de partida para priorizar defensas. A continuación repasamos las diez categorías con un ejemplo y su mitigación.
A01:2021 – Broken Access Control
El control de acceso roto encabeza la lista. Ocurre cuando un usuario puede actuar fuera de los permisos que le corresponden.
Ejemplo: un endpoint como GET /api/facturas/1043 devuelve la factura sin comprobar que pertenece al usuario autenticado. Cambiando el identificador (IDOR) se accede a datos ajenos.
Mitigación: denegar por defecto, verificar la propiedad del recurso en el servidor en cada petición y nunca confiar en identificadores enviados por el cliente. Centralizar la lógica de autorización.
A02:2021 – Cryptographic Failures
Fallos en la protección de datos sensibles en tránsito o en reposo, antes conocidos como "exposición de datos sensibles".
Ejemplo: almacenar contraseñas con MD5 sin sal, o servir un formulario de login por HTTP.
Mitigación: cifrar en tránsito con TLS, usar algoritmos de hashing lentos y con sal (bcrypt, argon2) para contraseñas, y no almacenar datos que no se necesiten.
A03:2021 – Injection
Datos no confiables se interpretan como comando o consulta. Incluye SQL, NoSQL, OS y LDAP injection, y también Cross-Site Scripting (XSS).
Ejemplo: concatenar entrada del usuario en una consulta:
-- Vulnerable
"SELECT * FROM users WHERE email = '" + email + "'"
-- Seguro (parametrizado)
"SELECT * FROM users WHERE email = ?"
Mitigación: usar consultas parametrizadas o un ORM, validar entradas con listas blancas y escapar la salida para prevenir XSS.
A04:2021 – Insecure Design
Categoría nueva en 2021: fallos de diseño que ninguna implementación perfecta puede corregir.
Ejemplo: un flujo de recuperación de contraseña basado solo en preguntas de seguridad cuyas respuestas son públicas (nombre del colegio, mascota).
Mitigación: modelado de amenazas desde la fase de diseño, patrones seguros de referencia y definir requisitos de seguridad antes de codificar.
A05:2021 – Security Misconfiguration
Configuraciones por defecto, permisos excesivos o servicios innecesarios expuestos.
Ejemplo: un panel de administración accesible con credenciales por defecto, o mensajes de error que revelan trazas completas de la pila.
Mitigación: hardening reproducible, deshabilitar funciones y cuentas que no se usen, revisar cabeceras de seguridad y automatizar la comprobación de la configuración.
A06:2021 – Vulnerable and Outdated Components
Uso de librerías, frameworks o dependencias con vulnerabilidades conocidas.
Ejemplo: una versión de una librería con un CVE crítico publicado que sigue en producción meses después.
Mitigación: mantener un inventario de dependencias (SBOM), analizar con herramientas de composición de software y aplicar parches con un ciclo definido.
A07:2021 – Identification and Authentication Failures
Fallos en la gestión de identidad y sesiones que permiten suplantar usuarios.
Ejemplo: permitir contraseñas triviales, no limitar intentos de login (fuerza bruta) o no invalidar la sesión al cerrar sesión.
Mitigación: autenticación multifactor, límite de intentos, gestión segura de sesiones e identificadores de sesión rotados tras el login.
A08:2021 – Software and Data Integrity Failures
Otra categoría nueva: asunciones sobre la integridad del código y los datos sin verificación.
Ejemplo: un pipeline de CI/CD que descarga dependencias o actualizaciones sin verificar firmas, abriendo la puerta a un ataque a la cadena de suministro.
Mitigación: verificar firmas digitales, usar repositorios de confianza y comprobar la integridad de los artefactos antes de desplegar.
A09:2021 – Security Logging and Monitoring Failures
Sin registro y monitorización adecuados, los incidentes pasan desapercibidos durante semanas.
Ejemplo: intentos de acceso fallidos que no se registran, de modo que un ataque de credenciales pasa inadvertido.
Mitigación: registrar eventos de seguridad relevantes (login, accesos denegados), centralizar logs, generar alertas y ensayar la respuesta ante incidentes.
A10:2021 – Server-Side Request Forgery (SSRF)
La aplicación obtiene un recurso remoto sin validar la URL proporcionada por el usuario.
Ejemplo: un servicio que descarga una imagen desde una URL indicada por el cliente y al que se le pasa http://169.254.169.254/ para leer metadatos internos del proveedor cloud.
Mitigación: validar y filtrar las URLs con listas blancas de destinos, bloquear rangos de red internos y desactivar redirecciones no necesarias.
Cómo usar el Top 10
El Top 10 no es una checklist exhaustiva, sino una guía de concienciación y priorización. Intégralo en el ciclo de desarrollo: revisiones de diseño, análisis estático y dinámico, y pruebas de penetración. Para una cobertura más completa conviene apoyarse en el OWASP ASVS (Application Security Verification Standard) como estándar de verificación detallado.
Cómo practicar el OWASP Top 10 sin quedarse en una lista
Para cada categoría crea una ficha con cuatro campos: condición vulnerable, señal observable, comprobación segura y control de mitigación. Trabaja en una aplicación deliberadamente vulnerable dentro de un laboratorio autorizado. Repite la prueba después de aplicar la corrección y guarda evidencia de ambos estados. Así conviertes una clasificación teórica en una revisión que un equipo de desarrollo puede incorporar a su ciclo de entrega.
Evita memorizar nombres sin entender el límite de confianza que se rompe. En control de acceso pregunta quién puede actuar sobre cada recurso; en inyección identifica qué dato termina interpretándose como instrucción; en configuración revisa qué valor inseguro llega a producción. El curso de Ethical Hacking ordena estas pruebas dentro de una metodología completa, siempre sobre sistemas propios o con autorización expresa.
Entrega sugerida: documenta un hallazgo con petici??n, respuesta, impacto, correcci??n y una segunda prueba que demuestre que el control aplicado bloquea el caso vulnerable.
Volver al blog de BLURTEK Academy