OWASP Top 10 2025 Explicado en Español: La Guía Definitiva con Ejemplos y PoCs
La guía definitiva del OWASP Top 10 2025 en español, categoría por categoría, con ejemplos y PoCs reales. Qué cambió, por qué, y cómo se ataca y defiende cada riesgo.
OWASP Top 10 2025 Explicado en Español: La Guía Definitiva con Ejemplos y PoCs
Categoría: Web Security · OWASP · Guía de Referencia Nivel: Fundamentos → Intermedio Tiempo de lectura: 22 min Actualizado: agosto 2026 Fuente oficial: top10.owasp.org/2025 Laboratorio asociado: CP01 Web Security Specialist · TribuCibernetica Cyber Range
El OWASP Top 10 es el documento de referencia más citado —y peor entendido— de la seguridad web. La mayoría lo memoriza como una lista. Aquí lo vas a entender: qué cambió en la edición 2025, por qué cambió, y cómo se ve cada riesgo en código real, del lado del que ataca y del que defiende. Todo validado contra la fuente oficial de OWASP.
Antes de empezar: es 2025, no "2026"
Un punto de precisión que importa, porque hay confusión en la comunidad. La edición vigente del OWASP Top 10 para aplicaciones web es la 2025, presentada en el Global AppSec de noviembre de 2025 y publicada como versión final. Reemplaza a la de 2021. OWASP publica una edición nueva cada 3-4 años, y esta es la primera actualización desde 2021.
Esta guía cubre esa edición 2025, categoría por categoría, con la fuente oficial enlazada en cada una. No es una traducción del documento de OWASP: es una explicación pensada en español, con el "por qué" de cada riesgo y ejemplos replicables — el enfoque que aplicamos en todo el blog de TribuCibernetica.
Índice
- Qué es el OWASP Top 10 y cómo se construye
- Qué cambió en 2025 (el mapa completo frente a 2021)
- A01:2025 — Broken Access Control
- A02:2025 — Security Misconfiguration
- A03:2025 — Software Supply Chain Failures (nueva)
- A04:2025 — Cryptographic Failures
- A05:2025 — Injection
- A06:2025 — Insecure Design
- A07:2025 — Authentication Failures
- A08:2025 — Software or Data Integrity Failures
- A09:2025 — Security Logging & Alerting Failures
- A10:2025 — Mishandling of Exceptional Conditions (nueva)
- Cómo practicar esto en el Cyber Range
- Glosario y referencias oficiales
1. Qué Es el OWASP Top 10 y Cómo se Construye
El OWASP Top 10 es un documento de concienciación que lista los diez riesgos de seguridad más críticos para aplicaciones web. No es una checklist exhaustiva ni un estándar de cumplimiento — es un punto de partida consensuado por la comunidad global de AppSec.
Lo importante para entenderlo: no se arma por opinión, se arma con datos. Para la edición 2025, el proyecto analizó datos de más de 2.8 millones de aplicaciones, con las vulnerabilidades mapeadas a cientos de CWEs (Common Weakness Enumerations). En vez de contar vulnerabilidades en bruto, OWASP usa la tasa de incidencia: el porcentaje de aplicaciones que tienen al menos una instancia de una debilidad dada. Ocho de las diez categorías salen de esos datos; las otras dos, de una encuesta a la comunidad sobre riesgos emergentes que los datos aún no capturan.
Un tema de fondo de la edición 2025: el desplazamiento de síntomas hacia causas raíz. Donde antes se hablaba de "exposición de datos sensibles" (un síntoma), se habla de "fallos criptográficos" (la causa). Guárdalo, porque explica varios de los cambios.
2. Qué Cambió en 2025 (el Mapa Completo Frente a 2021)
Hubo dos categorías nuevas y una consolidación. Este es el mapeo oficial completo:
| 2025 | Categoría | Movimiento desde 2021 |
|---|---|---|
| A01 | Broken Access Control | Se mantiene #1; ahora absorbe SSRF |
| A02 | Security Misconfiguration | Sube de #5 a #2 |
| A03 | Software Supply Chain Failures | NUEVA (expande "Vulnerable and Outdated Components") |
| A04 | Cryptographic Failures | Baja de #2 a #4 |
| A05 | Injection | Baja de #3 a #5 |
| A06 | Insecure Design | Baja de #4 a #6 |
| A07 | Authentication Failures | Se mantiene en #7 (renombrada) |
| A08 | Software or Data Integrity Failures | Se mantiene en #8 |
| A09 | Security Logging & Alerting Failures | Se mantiene en #9 (renombrada) |
| A10 | Mishandling of Exceptional Conditions | NUEVA |
Los tres titulares del cambio: SSRF dejó de ser una categoría propia (era el #10 en 2021) y se integró en Broken Access Control, porque OWASP lo considera fundamentalmente un fallo de control de acceso. Software Supply Chain Failures entra directo con la mayor tasa de incidencia de toda la lista. Y Security Misconfiguration pega el salto de #5 a #2 — reflejo de cuánto pesa hoy el despliegue continuo sin escaneo continuo.
3. A01:2025 — Broken Access Control
Posición: #1 (se mantiene desde 2021) · Fuente oficial: A01:2025
El control de acceso roto sigue siendo el riesgo #1, y no por poco: según los datos de OWASP, en promedio el 3.73% de las aplicaciones probadas tenía al menos uno de los 40 CWEs de esta categoría — la que más CWEs mapeados agrupa.
El modelo mental. El control de acceso decide qué puede hacer un usuario autenticado. Se rompe cuando la aplicación confía en algo que el usuario controla (un ID, un rol, un parámetro) para decidir permisos, en vez de verificarlo en el servidor contra la identidad real de quien pide.
Novedad 2025: esta categoría ahora incluye explícitamente SSRF (Server-Side Request Forgery), y los patrones de API BOLA (Broken Object Level Authorization — acceder al objeto de otro usuario manipulando su ID) y BFLA (Broken Function Level Authorization — invocar funciones de admin siendo usuario común).
Ejemplo — IDOR (un caso de BOLA):
GET /api/facturas/1023 HTTP/1.1
Authorization: Bearer <token_de_usuario_A>
# El usuario A cambia el ID a una factura que NO es suya:
GET /api/facturas/1024 HTTP/1.1
Authorization: Bearer <token_de_usuario_A>
# Si el servidor devuelve la factura 1024 (de otro usuario) sin
# verificar que pertenece a A → Broken Object Level Authorization.
Cómo se defiende: deniega por defecto; verifica la autorización en el servidor, por objeto y por función, en cada petición; nunca confíes en un ID o rol enviado por el cliente; usa identificadores impredecibles; aplica menor privilegio. La regla es simple: la autenticación prueba quién eres; la autorización decide qué puedes tocar — y esa segunda decisión es siempre del servidor.
4. A02:2025 — Security Misconfiguration
Posición: #2 (subió desde #5) · Fuente oficial: A02:2025
El salto de #5 a #2 es la historia de la seguridad moderna en una línea: desplegamos rápido y configuramos mal. El 3.00% de las aplicaciones tenía al menos uno de los 16 CWEs de esta categoría.
El modelo mental. No es un bug en el código; es el sistema mal ajustado: paneles de administración expuestos, credenciales por defecto sin cambiar, cabeceras de seguridad ausentes, mensajes de error verbosos, permisos de nube demasiado abiertos, features de debug encendidas en producción.
Ejemplo — mensaje de error que filtra el stack:
# Una app en producción con el modo debug activado responde:
HTTP/1.1 500 Internal Server Error
...
Traceback (most recent call last):
File "/app/views.py", line 42, in get_user
conn = psycopg2.connect("dbname=prod user=admin password=S3cr3t...")
# El atacante acaba de recibir la ruta interna, la librería, el
# usuario de BD y parte de las credenciales. Regalo de configuración.
Cómo se defiende: endurecimiento (hardening) reproducible por entorno; sin credenciales por defecto; deshabilitar debug y features innecesarias en producción; cabeceras de seguridad; revisión continua de configuración — no una sola vez, sino en cada despliegue (el CI/CD sin escaneo continuo es lo que dispara esta categoría).
5. A03:2025 — Software Supply Chain Failures (Nueva)
Posición: #3 · NUEVA · Fuente oficial: A03:2025
Es la categoría nueva estrella de 2025, y entró con la mayor tasa de incidencia de toda la lista. Expande la vieja "Componentes Vulnerables y Desactualizados" para abarcar todo el ecosistema: dependencias, sistemas de build, infraestructura de distribución, y las herramientas de desarrollo.
El modelo mental. Tu aplicación no es solo tu código. Es tu código más cientos de dependencias, más el pipeline que las compila, más los registros de donde las bajas. Un compromiso en cualquier eslabón —una dependencia con una puerta trasera, un paquete suplantado (typosquatting), un build server comprometido— es un compromiso de tu aplicación. Los ataques a xz/liblzma y a paquetes de npm de años recientes son el ejemplo vivo.
Ejemplo — dependency confusion (conceptual):
# Tu empresa usa un paquete interno llamado "tribu-utils",
# alojado en un registro privado.
# El atacante publica un paquete PÚBLICO llamado "tribu-utils"
# con una versión más alta.
# Si tu gestor de paquetes está mal configurado y prioriza el
# registro público por número de versión, descarga y ejecuta el
# paquete del atacante en tu build. Compromiso de cadena de suministro.
Cómo se defiende: genera y mantén un SBOM (Software Bill of Materials); fija versiones y verifica integridad (hashes, firmas); monitorea dependencias por vulnerabilidades conocidas; controla la configuración de tus registros para evitar dependency confusion; verifica la integridad del pipeline de build.
6. A04:2025 — Cryptographic Failures
Posición: #4 (bajó desde #2) · Fuente oficial: A04:2025
Aquí vive el ejemplo perfecto del giro "síntoma → causa raíz": en 2021 esta categoría se llamaba en esencia "exposición de datos sensibles" (el síntoma); ahora se nombra por la causa: fallos criptográficos.
El modelo mental. Los datos sensibles se exponen no porque "se filtren" mágicamente, sino porque la criptografía que debía protegerlos falló o faltó: cifrado ausente, algoritmos obsoletos (MD5, SHA1, DES), claves mal gestionadas, TLS mal configurado, hashing de contraseñas débil.
Ejemplo — hashing de contraseñas roto:
# MAL: hash rápido y sin sal. Crackeable en segundos con una GPU.
import hashlib
hash = hashlib.md5(password.encode()).hexdigest()
# BIEN: función de derivación lenta, con sal, resistente a GPU.
import bcrypt
hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
Cómo se defiende: TLS 1.2+ con forward secrecy; hashing moderno de contraseñas (bcrypt, argon2, scrypt); evitar primitivas obsoletas; gestión de claves adecuada; y —mirando al futuro— preparación para criptografía post-cuántica, que OWASP ya menciona explícitamente en las recomendaciones de 2025.
7. A05:2025 — Injection
Posición: #5 (bajó desde #3) · Fuente oficial: A05:2025
Que Injection haya bajado del #3 al #5 no significa que sea menos peligrosa — significa que otras categorías crecieron más rápido. La inyección sigue siendo de las más devastadoras: SQL, NoSQL, comandos de OS, LDAP, y por supuesto XSS, que OWASP clasifica dentro de esta categoría.
El modelo mental. La inyección ocurre cuando datos no confiables se mezclan con código (una consulta, un comando) y el intérprete no puede distinguir uno de otro. Es la misma raíz conceptual que explicamos a fondo en nuestra saga de SQL Injection: el problema es la mezcla de código y datos.
Ejemplo — SQL injection clásica:
-- La app construye la consulta concatenando input del usuario:
"SELECT * FROM usuarios WHERE nombre = '" + input + "'"
-- El atacante envía como "input":
' OR '1'='1
-- La consulta resultante devuelve TODOS los usuarios:
SELECT * FROM usuarios WHERE nombre = '' OR '1'='1'
Cómo se defiende: consultas parametrizadas (prepared statements) — la única solución estructural real, porque separan código de datos de raíz; validación de entrada; escape contextual para XSS; y menor privilegio en el usuario de base de datos.
Profundiza: este riesgo lo desarrollamos hasta el hueso en nuestra saga de 9 tomos de SQL Injection — desde la anatomía hasta la explotación avanzada con sqlmap, WAF bypass y SQLi→RCE. Si quieres dominar Injection de verdad, empieza por el Tomo 1.
8. A06:2025 — Insecure Design
Posición: #6 (bajó desde #4) · Fuente oficial: A06:2025
El modelo mental. Esta categoría es distinta a todas: no habla de bugs de implementación, sino de fallos de diseño. Una aplicación puede estar perfectamente codificada —sin un solo bug— y ser insegura porque su diseño no contempló el abuso. "Control de diseño ausente o inefectivo", en palabras de OWASP.
Ejemplo conceptual: un flujo de recuperación de contraseña que usa preguntas de seguridad con respuestas públicas (nombre de tu mascota, ciudad natal) está mal diseñado, aunque cada línea de código funcione. El defecto no se arregla con un parche: se arregla rediseñando el flujo.
Por su naturaleza, esta categoría no se demuestra con un PoC de una línea — se aborda con modelado de amenazas (threat modeling), patrones de diseño seguros, y pensar en el abuso desde la fase de arquitectura, no después.
Cómo se defiende: threat modeling desde el diseño; patrones seguros reutilizables ("paved roads"); historias de abuso junto a las historias de usuario; separación de responsabilidades y límites de confianza claros.
9. A07:2025 — Authentication Failures
Posición: #7 (se mantiene) · Fuente oficial: A07:2025
El modelo mental. Mientras el control de acceso (A01) decide qué puedes hacer, la autenticación prueba quién eres. Falla cuando un atacante logra que el sistema lo reconozca como un usuario legítimo que no es: credenciales débiles o por defecto, fuerza bruta sin límite, gestión de sesiones rota, ausencia de MFA, enumeración de cuentas.
Ejemplo — enumeración de usuarios por mensajes distintos:
# El login responde diferente según exista o no el usuario:
POST /login (usuario inexistente) → "El usuario no existe"
POST /login (usuario válido, pass mala) → "Contraseña incorrecta"
# El atacante ahora puede ENUMERAR qué usuarios existen antes
# de siquiera intentar la fuerza bruta. Respuesta correcta:
# un mensaje idéntico y genérico en ambos casos.
Cómo se defiende: MFA; validación de claims en JWT; verificación contra listas de credenciales filtradas; prevención de enumeración de cuentas; límites de intentos; gestión de sesión robusta.
10. A08:2025 — Software or Data Integrity Failures
Posición: #8 (se mantiene) · Fuente oficial: A08:2025
El modelo mental. Ocurre cuando código o datos que deberían ser verificados se tratan como confiables sin comprobar su integridad: actualizaciones sin firmar, deserialización insegura, pipelines de CI/CD que aceptan artefactos no verificados.
La diferencia con A03 (Supply Chain): A03 mira todo el ecosistema y la cadena de suministro; A08 se enfoca en garantizar que lo que se ejecuta y almacena no fue alterado (firmas, actualizaciones seguras, serialización segura). Son primos, pero distintos.
Ejemplo — deserialización insegura (conceptual): una app que deserializa un objeto enviado por el usuario sin validarlo puede ejecutar código arbitrario incrustado en ese objeto. El dato "de confianza" era, en realidad, un payload.
Cómo se defiende: firmas digitales en actualizaciones y artefactos; evitar deserialización de datos no confiables (o usar formatos seguros); verificación de integridad en el pipeline.
11. A09:2025 — Security Logging & Alerting Failures
Posición: #9 (se mantiene, renombrada) · Fuente oficial: A09:2025
El modelo mental. No es una vulnerabilidad que el atacante explote directamente — es la que hace que no te enteres de que te están explotando. Sin logging ni alertas adecuadas, un ataque puede desarrollarse durante meses sin ser detectado. El renombrado 2025 añade "Alerting" para subrayar que registrar no basta: hay que alertar.
Ejemplo — lo que deberías estar registrando y alertando: intentos de login fallidos en volumen (fuerza bruta), accesos denegados repetidos (sondeo de control de acceso), errores de validación de entrada en ráfaga (alguien probando payloads de inyección). Si nada de esto genera una alerta, el SOC está ciego.
Cómo se defiende: registrar eventos de seguridad relevantes con contexto suficiente; centralizar en un SIEM; alertas sobre patrones sospechosos; y proteger los propios logs contra manipulación. Este es el terreno de nuestra ruta CP09 Blue Team/SOC, y la razón por la que cada tomo técnico del blog incluye reglas de detección (Sigma/SIEM).
12. A10:2025 — Mishandling of Exceptional Conditions (Nueva)
Posición: #10 · NUEVA · Fuente oficial: A10:2025
La segunda categoría nueva de 2025. Cubre lo que pasa cuando un programa no previene, no detecta o no responde bien a situaciones inusuales e impredecibles.
El modelo mental. OWASP la descompone en tres fallos posibles: la aplicación no evita que ocurra una situación anormal, no la identifica cuando está ocurriendo, y/o responde mal (o no responde) después. Incluye "failing open" (fallar hacia el estado inseguro), manejo indebido de errores, errores lógicos y condiciones de carrera (race conditions).
Ejemplo — failing open:
# Un control de autorización que, si el servicio de permisos
# no responde, deja pasar al usuario "para no romper la experiencia":
try:
permitido = servicio_permisos.check(usuario, recurso)
except TimeoutError:
permitido = True # ← FAILING OPEN. Ante el error, abre la puerta.
# Lo correcto es "failing closed": ante la duda, DENIEGA.
Cómo se defiende: fallar siempre hacia el estado seguro (fail closed); manejo de errores explícito y probado; cobertura de condiciones anómalas en las pruebas; y detección de comportamiento (esta categoría, como A03, no se atrapa con firmas conocidas, sino observando anomalías).
13. Cómo Practicar Esto en el Cyber Range
Leer el OWASP Top 10 te da el mapa. Dominarlo requiere explotar y defender cada riesgo con las manos. En la ruta CP01 — Web Security Specialist del Cyber Range de TribuCibernetica practicas los riesgos explotables de esta lista en entornos reales y en español: control de acceso roto (IDOR/BOLA), inyección, misconfiguration, fallos criptográficos y más. Los riesgos de detección y defensa (A09) se trabajan en la ruta CP09 — Blue Team/SOC.
Y para los dos riesgos que dan para saga propia:
- Injection (A05) → nuestra saga de 9 tomos de SQL Injection, de la anatomía a la explotación avanzada.
- Riesgos de IA → si trabajas con LLMs, el OWASP Top 10 web se queda corto: existe un Top 10 específico para aplicaciones LLM, que cubrimos en nuestra guía de OWASP LLM Top 10 y en nuestra serie de AI Security.
→ Empieza en CP01 gratis → Únete al Discord
14. Glosario y Referencias Oficiales
| Término | Definición |
|---|---|
| CWE | Common Weakness Enumeration — catálogo de MITRE de tipos de debilidades de software |
| Tasa de incidencia | % de aplicaciones con al menos una instancia de una debilidad; base del ranking OWASP |
| BOLA | Broken Object Level Authorization — acceder a objetos de otro usuario manipulando su ID |
| BFLA | Broken Function Level Authorization — invocar funciones privilegiadas siendo usuario común |
| IDOR | Insecure Direct Object Reference — referencia directa insegura a objetos (caso de BOLA) |
| SSRF | Server-Side Request Forgery — forzar al servidor a hacer peticiones a destinos elegidos por el atacante |
| SBOM | Software Bill of Materials — inventario de todos los componentes de un software |
| Fail closed / open | Fallar hacia el estado seguro (closed) o inseguro (open) ante un error |
Referencias oficiales de OWASP:
- OWASP Top 10:2025 (índice oficial) — top10.owasp.org/2025
- Introducción y metodología 2025 — Introduction
- Repositorio oficial del proyecto — github.com/OWASP/Top10
- Cada categoría A01–A10 enlazada en su sección correspondiente arriba
Guía elaborada por TribuCibernetica con base en la edición oficial OWASP Top 10:2025, validada contra top10.owasp.org/2025 en agosto de 2026. El OWASP Top 10 se publica bajo licencia Creative Commons. Este contenido es una explicación educativa independiente, no un documento oficial de OWASP. Practica las técnicas ofensivas exclusivamente en entornos autorizados; en México, el acceso no autorizado a sistemas constituye delito (Art. 211 bis del Código Penal Federal).