El OWASP Top 10 explicado categoría a categoría, en español y con ejemplos reales: control de acceso roto, inyecciones, SSRF, fallos criptográficos y más. Con enlaces a la teoría y a labs prácticos de cada fallo.
Gorka El Bochi
Fundador de BBLABS
Respuesta rápida: El OWASP Top 10 es la lista de referencia de las 10 categorías de riesgo de seguridad web más críticas, mantenida por la fundación OWASP. La versión oficial vigente es la de 2021 (con un release candidate de 2025 en marcha). No es una lista de vulnerabilidades sueltas, sino de familias de riesgo que todo hunter y desarrollador debería dominar.
El OWASP Top 10 es un documento de concienciación que publica la Open Worldwide Application Security Project (OWASP) cada pocos años. Resume, a partir de datos reales de miles de aplicaciones, las diez categorías de riesgo más graves y frecuentes en seguridad web.
Importa por dos motivos:
La versión estable y citada en la mayoría de programas es la de 2021. OWASP publicó en 2025 un release candidate de la próxima edición; la estructura final puede cambiar, así que aquí explico la lista 2021 (la oficial) y anoto al final hacia dónde va 2025.
Pasó al número 1 en 2021: fue la categoría con más incidencia de todas. Ocurre cuando un usuario puede hacer o ver cosas que no le corresponden: leer datos de otra cuenta, acceder a funciones de admin o saltarse restricciones.
Ejemplo real: cambias /api/orders/123 por /api/orders/124 y ves el pedido (y la dirección) de otro cliente. Eso es un IDOR, el caso más común de esta familia.
Profundiza en Broken Access Control y en IDOR; la teoría práctica está en Academy · IDOR & Broken Access Control.
Antes llamada "Sensitive Data Exposure". Cubre datos sensibles mal protegidos: tráfico sin TLS, contraseñas con hashes débiles (MD5/SHA1 sin sal), claves en el código, cifrado mal implementado.
Ejemplo real: una API que devuelve los números de tarjeta completos en la respuesta JSON, o un login que viaja por HTTP plano en una red pública. El atacante no "rompe" la cripto: aprovecha que casi no hay.
Una de las familias más antiguas y peligrosas. Ocurre cuando datos del usuario se mezclan con un comando o consulta sin separarlos correctamente. En 2021, XSS pasó a formar parte de esta categoría.
Incluye varios fallos que tienen su propia página:
Ejemplo real: un buscador que construye la query con "SELECT * FROM users WHERE name = '" + input + "'" permite ' OR '1'='1 para volcar toda la tabla. Practica el patrón en Academy · XSS y Academy · SQLi.
Nueva en 2021. No es un bug de implementación, sino un fallo en el diseño: faltó pensar en el abuso desde el principio. No se arregla con un parche puntual; hay que rediseñar el flujo.
Ejemplo real: un proceso de transferencia que comprueba el saldo y lo descuenta en dos pasos no atómicos permite gastar el dinero dos veces enviando peticiones en paralelo. Eso entra en Race Condition y en la lógica de negocio, que es de lo que más paga porque no se detecta con escáneres.
Servidores, frameworks o servicios con ajustes por defecto inseguros: paneles de admin expuestos, mensajes de error verbose, CORS mal configurado, buckets S3 públicos, directorios listables.
Ejemplo real: un /.git/ accesible desde el navegador permite descargar el código fuente completo de la aplicación. O un CORS con Access-Control-Allow-Origin reflejado que permite leer datos cross-origin: lo tienes explicado en CORS y XXE.
Usar librerías, frameworks o dependencias con vulnerabilidades conocidas. No tienes que descubrir el fallo: ya tiene CVE; solo hay que encontrar dónde sigue sin parchear.
Ejemplo real: Log4Shell (CVE-2021-44228), la vulnerabilidad en la librería Log4j que en 2021 permitió RCE en medio internet con solo enviar una cadena en un campo de texto. Millones de sistemas afectados por una dependencia desactualizada.
Antes "Broken Authentication". Cubre logins débiles: permitir fuerza bruta, gestión de sesión rota, 2FA saltable, recuperación de contraseña insegura, tokens JWT mal validados.
Ejemplo real: un endpoint de verificación OTP sin límite de intentos permite probar los 1.000.000 de códigos de 6 dígitos. O un JWT firmado con alg: none que el servidor acepta. Tienes la profundización en Auth Bypass, Academy · Authentication Bypass y Academy · OAuth.
Nueva en 2021. Confiar en código, actualizaciones o datos sin verificar su integridad. Incluye deserialización insegura y los ataques de cadena de suministro (supply chain).
Ejemplo real: el ataque a SolarWinds (2020), donde se insertó código malicioso en una actualización legítima de software que después se distribuyó a miles de organizaciones. La confianza ciega en el origen fue el fallo.
No registrar eventos de seguridad, o no alertar sobre ellos, hace que los ataques pasen desapercibidos durante meses. Rara vez es un bounty directo, pero amplifica el impacto de todos los demás.
Ejemplo real: una empresa que tarda 200 días en darse cuenta de una brecha porque nadie vigilaba los logins fallidos masivos ni los accesos anómalos a datos.
Añadida en 2021 por votación de la comunidad. El atacante consigue que el servidor haga peticiones a destinos que el atacante elige: la red interna, servicios no expuestos o el metadata del cloud.
Ejemplo real: la brecha de Capital One (2019). Un SSRF permitió llegar al endpoint de metadata de AWS (169.254.169.254), robar credenciales IAM y acceder a los datos de más de 100 millones de clientes. Es el ejemplo de manual de por qué el SSRF está en el Top 10: profundiza en SSRF y Academy · SSRF.
| # | Categoría | Fallo estrella | Práctica |
|---|---|---|---|
| A01 | Broken Access Control | IDOR | /vulnerabilidades/idor |
| A02 | Cryptographic Failures | Datos sin cifrar | — |
| A03 | Injection | SQLi, XSS | /vulnerabilidades/sqli |
| A04 | Insecure Design | Lógica de negocio | /vulnerabilidades/business-logic |
| A05 | Security Misconfiguration | CORS, S3 público | /vulnerabilidades/cors |
| A06 | Componentes vulnerables | Log4Shell | — |
| A07 | Auth Failures | JWT, OTP | /vulnerabilidades/auth-bypass |
| A08 | Integridad de datos | Deserialización | /vulnerabilidades/ssti |
| A09 | Logging & Monitoring | Falta de logs | — |
| A10 | SSRF | Cloud metadata | /vulnerabilidades/ssrf |
OWASP publicó en 2025 un release candidate de la próxima edición. Como toda revisión, se basa en datos más recientes y en una encuesta a la comunidad, y la lista definitiva puede variar respecto al borrador. La dirección general apunta a dar más peso a la cadena de suministro de software (el riesgo que ya empezó a captar A08 en 2021) y a reorganizar algunas categorías de inyección y configuración.
Consejo práctico: no memorices el número exacto de cada categoría. Lo que importa de verdad es entender las familias de fallos y saber reconocerlas en una aplicación real. Cuando salga la versión final de 2025, los conceptos serán los mismos; solo cambiará el orden y las etiquetas.
¿El OWASP Top 10 es una lista de vulnerabilidades?
No exactamente. Son categorías de riesgo. Dentro de "Injection" caben SQLi, XSS, command injection, etc. Es un mapa de familias, no un catálogo de CVEs.
¿Tengo que aprenderme las 10 de memoria para hacer bug bounty?
No de memoria, pero sí entenderlas. Te dan el vocabulario común con los equipos de seguridad y te orientan sobre dónde mirar primero.
¿Cuál es la categoría que más paga?
Las que tocan dinero, datos o ejecución de código: Broken Access Control (A01), Injection (A03) y SSRF (A10) concentran muchos de los reportes mejor pagados.
¿Dónde practico todo esto?
En los labs de BBLABS reproduces fallos reales de cada familia, en orden con el roadmap. La teoría categoría a categoría está en el diccionario de vulnerabilidades.
El OWASP Top 10 es el mejor punto de partida para ordenar la cabeza: en lugar de mil fallos sueltos, diez familias que cubren la inmensa mayoría de lo que vas a encontrar. Domina control de acceso, inyección y SSRF antes que nada (son lo más frecuente y lo mejor pagado), apóyate en la teoría del diccionario de vulnerabilidades y conviértela en reflejo practicando labs de casos reales.
hunters entrenando
labs de reportes reales
completaciones
en bounties practicados
Crea tu cuenta gratis y practica sobre labs basados en reportes reales que pagaron miles de euros. La Academy es gratis para siempre.
Sin tarjeta · Academy gratis · cancela cuando quieras
Aprende a identificar y explotar vulnerabilidades IDOR (Insecure Direct Object Reference) en aplicaciones web. Desde los conceptos básicos hasta la escritura de reportes efectivos.
Qué es el bug bounty, cómo funciona un programa paso a paso, en qué plataformas se hace (HackerOne, Bugcrowd, Intigriti, YesWeHack), cuánto se gana, si es legal y por dónde empezar desde cero.
Cuánto paga de verdad el bug bounty: recompensas medias por tipo de vulnerabilidad y severidad, lo que ganan los top hunters, la realidad para principiantes y por qué la mayoría no vive de esto.