OWASP Top 10: el ranking de vulnerabilidades que tu desarrollador todavía ignora

Cuando un atacante mira tu aplicación, no piensa en categorías abstractas. Piensa en una pregunta concreta: “¿qué de esto puedo romper en menos de 8 horas?”.

Su respuesta empieza por OWASP Top 10. Tu defensa también debería.

Este post no es otra explicación de qué es el Top 10. Es la guía operativa que te dice qué auditar, en qué orden, con qué herramienta concreta — y cómo cada categoría se materializa en sitios reales (con casos verificables públicamente).

El estado actual: OWASP Top 10:2021

La versión vigente fue publicada el 24 de septiembre de 2021. La actualización (2025 o 2026) está en preparación pública en GitHub.

Las 10 categorías de riesgo:

Dato clave: el 94% de las aplicaciones probadas tenía al menos 1 instancia de Broken Access Control (A01). Es la #1 con razón (fuente: OWASP datos 2017-2020 públicos).

A01 — Broken Access Control: la realidad incómoda

Qué es: el usuario puede acceder a recursos o funciones que no debería.

Ejemplos reales (públicos):

• Optus 2022: 9.8 millones de clientes expuestos. Causa: API de identificación que permitía iterar IDs de cliente sin autenticación. Esto es A01.
• Twitter 2022: 5.4 millones de cuentas vinculadas a teléfonos por bug en API. A01.
• T-Mobile 2023: 37 millones de cuentas. API que devolvía datos de cualquier cuenta sin auth real. A01.

Cómo se detecta:

1. Burp Suite + autorización matrix: probar cada endpoint con 2 usuarios distintos
2. OWASP ZAP con context de autenticación
3. Pruebas IDOR manuales: cambiar IDs en URLs y body params
4. Análisis de logs: buscar respuestas 200 a paths que deberían dar 403

Cómo lo cubre Pentest C360: detección automatizada de paths sensibles expuestos sin auth (admin, .env, .git, debug endpoints, swagger sin gate). Mapeo a CWE-22 (Path Traversal), CWE-284 (Improper Access Control), CWE-287 (Improper Authentication).

A02 — Cryptographic Failures

Qué es: datos sensibles transmitidos o almacenados sin cifrado adecuado.

Top errores que vemos en auditorías:

• TLS 1.0 / 1.1 todavía habilitado (deprecated desde 2020 por IETF RFC 8996)
• Cifrados débiles: RC4, 3DES, MD5
• Certificados auto-firmados en producción
• HSTS sin preload ni includeSubDomains
• Cookies sensibles sin Secure ni HttpOnly ni SameSite=Strict
• Tokens JWT con algoritmo none o secret débil
• Passwords almacenadas con MD5/SHA-1 plain (o sin salt)

Detección automática:

# SSL Labs — análisis profundo (oficial)
curl -s "https://api.ssllabs.com/api/v3/analyze?host=ejemplo.com"

# testssl.sh — auditoría TLS local
testssl.sh --color 0 https://ejemplo.com

# Mozilla Observatory — headers + TLS
curl -s "https://http-observatory.security.mozilla.org/api/v1/analyze?host=ejemplo.com" -X POST

Pentest C360 ejecuta los 3 + scoring agregado.

A03 — Injection (incluye XSS)

Subcategorías que importan:

• SQL Injection (CWE-89): el más común y más letal
• NoSQL Injection (MongoDB, Redis): menos cubierto, igual de peligroso
• Command Injection (CWE-78): os.system() con input no sanitizado
• LDAP Injection: enterprise apps
• XSS (CWE-79): movido aquí desde su propia categoría
• Server-Side Template Injection (SSTI): Jinja2, Twig, ERB

Caso público: Equifax 2017. 147 millones de personas. Causa: Apache Struts CVE-2017-5638 (RCE via Content-Type). Patch llevaba 2 meses publicado. A03 + A06.

Detección:

• sqlmap para SQLi: el clásico, sigue funcionando
• DalFox para XSS reflejado y DOM
• OWASP ZAP active scan (cuidado en producción)
• Semgrep en CI/CD: detecta patrones inseguros en código antes de deploy

A04 — Insecure Design (categoría NUEVA en 2021)

Esta es la más difícil de auditar automáticamente. No es un bug, es una decisión de arquitectura.

Ejemplos:

• API de reset de password que envía link sin validar email del solicitante
• Endpoint de “recordar dispositivo” que usa cookies sin TTL
• Sistema de cupones que permite combinar promociones que no deberían combinarse
• Storage de archivos con nombres predecibles

Cómo se ataca este Top 10: con threat modeling. STRIDE (Microsoft) o PASTA (TM frameworks). Si tu equipo no hace threat modeling antes de cada feature, A04 está abierto.

A05 — Security Misconfiguration

El más común que detectamos:

Pentest C360 detecta cada uno automáticamente. La buena noticia: los headers son configuración, no código. Se arreglan en horas, no semanas.

A06 — Vulnerable and Outdated Components

El veneno silencioso: tu app puede ser perfecta, pero si tu dependencia tiene CVE publicado de hace 6 meses, estás expuesto.

Detección obligatoria:

• Dependabot (GitHub) — gratis, automático
• OWASP Dependency-Check — CLI, gratis
• Snyk — UI bonita, plan gratis suficiente para starters
• CISA Known Exploited Vulnerabilities (catálogo oficial): si una CVE está aquí, es exploit confirmado en wild

Verificación independiente: NVD (nvd.nist.gov) tiene el catálogo oficial de CVEs. Cada audit que ejecutas en Pentest C360 cruza componentes detectados contra NVD + CISA KEV.

A07 — Authentication Failures

Los 5 errores que vemos cada semana:

1. Sin rate limit en login → bruteforce
2. Recovery por SMS → SIM swap
3. JWT en localStorage (vulnerable a XSS) en lugar de httpOnly cookie
4. Sin MFA en cuentas admin
5. Session ID predecible o sin rotación post-login

Verizon DBIR 2024: el 74% de breaches involucran credenciales humanas comprometidas. MFA bien implementado reduce esto en 99.9% según estudio Microsoft 2019 (replicado en 2023).

A08 — Software and Data Integrity Failures

Casos que trajo SolarWinds (2020):

• Auto-updates sin verificación de firma
• CI/CD pipelines comprometidos
• Dependencias desde repos que pueden ser tomados (typosquatting)
• Deserialización insegura (Java, .NET, Python pickle)

Mitigaciones:

• SLSA (Supply chain Levels for Software Artifacts) — framework de Google
• Sigstore para firmar artifacts
• SBOM (Software Bill of Materials) — CISA lo pide para vendor risk management

A09 — Security Logging and Monitoring Failures

El test del minuto: ¿cuánto tarda tu equipo en saber que alguien intentó login con admin/admin a las 3 AM?

Si la respuesta es “más de 5 minutos”, A09 abierto.

Stack mínimo:

• CrowdSec (gratis, código abierto) o Wazuh
• Logs estructurados (JSON, no texto plano)
• Centralización: ELK, Loki, Splunk, Graylog
• Alertas: Slack/Discord/PagerDuty con thresholds claros

A10 — Server-Side Request Forgery (SSRF)

Categoría nueva en 2021, motivada por casos como Capital One 2019. Atacante usó SSRF para acceder al metadata service de AWS (169.254.169.254) y robó credenciales IAM. 100 millones de personas afectadas.

Detección:

• Cualquier endpoint que acepte URLs como input → punto sospechoso
• Validar que la URL apunte a un dominio whitelisted
• Bloquear IPs internas (127.0.0.1, 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• En cloud: usar IMDSv2 (token-based) en lugar de IMDSv1

El plan de remediación de 30 días

Semana 1 (6 horas operacional): - Audit con Pentest C360 → mapeo a OWASP A01-A10 - Fix de A05 (Security Misconfiguration): headers, Permissions-Policy, HSTS preload - Fix de A02 parcial: TLS 1.2/1.3 only

Semana 2: - Implementar Dependabot + Snyk - Fix CVEs críticos (CVSS ≥ 7) - Setup CrowdSec + Wazuh

Semana 3: - Code review de A01 (access control) — endpoint por endpoint - MFA en todas las cuentas admin (A07)

Semana 4: - Threat modeling de features nuevos (A04) - Audit con sitio modelo (benchmark) — Pentest C360 lo incluye nativo - Re-audit completo → MTTR cuantificado

Resultado típico: de risk score 50-80 a risk score 0-5 en 30 días.

La pregunta que debes hacerte hoy

¿Cuál de los A01-A10 está más expuesto en tu sitio ahora mismo?

Si no puedes responderlo con número de hallazgos por categoría, el primer audit es gratis. El motor mapea cada finding a OWASP + CWE + URL de validación independiente.

El miedo es real. La buena noticia: las categorías son finitas, las herramientas son maduras, y el patrón replicable de auditoría → fix → re-audit → MTTR cuantificado funciona. Lo demostramos en 31 dominios públicos.