Pentesting web: guía completa de pentesting de aplicaciones

Un pentesting web (o pentesting de aplicaciones web) es un ataque manual y autorizado contra una aplicación web para encontrar fallos de seguridad explotables antes de que lo haga un atacante real. Va mucho más allá de pasar un escáner: el equipo combina automatización con criterio humano, encadena vulnerabilidades, abusa de la lógica de negocio y entrega un informe con prueba de concepto reproducible y severidad CVSS justificada. En España es la prueba técnica que evidencia controles obligatorios en NIS2, DORA, ENS, ISO 27001 y PCI DSS sobre cualquier aplicación expuesta a Internet.

Esta guía cubre qué es exactamente un pentesting web, las fases, las vulnerabilidades más explotadas en 2025-2026, la diferencia con SAST, DAST y WAF, y cómo elegir un proveedor que aporte valor real al ciclo de desarrollo.

Qué es un pentesting web

Un pentesting web es un ejercicio ofensivo autorizado y acotado sobre una o varias aplicaciones HTTP/HTTPS de la organización: portales corporativos, paneles de administración, e-commerce, plataformas SaaS, APIs REST y GraphQL, aplicaciones internas. El objetivo no es contar vulnerabilidades teóricas, es demostrar qué fallos reales tiene la aplicación, cómo se explotan y qué impacto tendrían si llegaran a un atacante motivado.

A diferencia de un escáner web automático (Nuclei, Acunetix, Burp Scanner, ZAP), un pentesting web profesional:

• Encadena vulnerabilidades que individualmente parecen menores. Una fuga de información que filtra emails internos, un IDOR que permite ver perfiles ajenos y un SSRF a metadata de cloud pueden combinarse en una toma completa del entorno de producción.
• Audita la lógica de negocio, no sólo los patrones técnicos. Un escáner detecta una inyección SQL; un pentester detecta que aplicar el cupón "ADMIN10" tres veces da el producto gratis o que cambiar el rol de usuario en un body JSON oculto otorga permisos de administrador.
• Entrega prueba de concepto reproducible: capturas de request y response, scripts mínimos viables, vídeo del ataque cuando hace falta. Sin eso, el equipo de desarrollo no tiene cómo arreglar.
• Justifica severidad CVSS según impacto en el negocio, no según una tabla genérica.

La duración típica de un pentesting web va de 5 a 15 días laborables según el tamaño de la aplicación, su superficie y la metodología pactada.

Por qué hacer pentesting web: el valor real para el negocio

Las aplicaciones web son el vector de entrada más común en los incidentes que afectan a empresas españolas según los informes anuales del INCIBE. Tres cifras que cualquier CISO conoce:

• Más del 70% de las brechas con datos exfiltrados empiezan en una aplicación web mal configurada o sin parchear.
• El coste medio de remediación tras un incidente con datos personales triplica el coste de un pentesting anual completo.
• El tiempo medio entre que un atacante explota una vulnerabilidad web y se alcanza la persistencia interna es inferior a 24 horas en organizaciones sin SOC.

Bien ejecutado, un pentesting web entrega cinco resultados concretos:

1. Inventario priorizado de fallos reales con severidad justificada, no listas largas sin contexto.
2. Evidencias reproducibles para que desarrollo arregle sin adivinar.
3. Cumplimiento normativo demostrable ante auditorías NIS2, ENS, ISO 27001 o PCI DSS.
4. Lectura honesta del estado que puedes presentar a comité, junta o cliente B2B durante una due diligence.
5. Reducción medible del riesgo tras corregir y pasar el retest.

Pentesting web vs SAST, DAST y WAF: cómo encajan

En cualquier programa de seguridad de aplicaciones (AppSec) conviven cuatro capas. Confundirlas lleva a comprar lo que no se necesita:

• SAST (Static Application Security Testing). Análisis estático del código fuente. Detecta patrones inseguros en el código antes de compilar. Lo usa el equipo de desarrollo durante el ciclo de integración continua (CI).
• DAST (Dynamic Application Security Testing). Análisis dinámico automático sobre la aplicación corriendo. Lanza payloads contra la aplicación expuesta y mira las respuestas. Es lo que hacen Acunetix, ZAP, Burp Scanner y similares. Detecta lo automatizable.
• Pentesting web. Análisis manual con herramientas. Encadena vulnerabilidades, abusa de lógica de negocio, valida explotabilidad real. Lo que no detecta un DAST.
• WAF (Web Application Firewall). Capa defensiva delante de la aplicación que bloquea ataques conocidos. No arregla las vulnerabilidades, las mitiga temporalmente.

La regla rápida: SAST y DAST se integran en CI/CD para detectar lo barato y rápido. El pentesting web se contrata periódicamente para detectar lo que la automatización no ve. El WAF protege el perímetro mientras se arreglan los hallazgos. Las cuatro capas son complementarias, no alternativas.

Tipos de aplicación web y cómo cambia el pentesting

El "pentesting web" cambia según la naturaleza de la aplicación:

• E-commerce y marketplace. Foco en gestión de pedidos, cupones, carrito, pasarela de pago, devoluciones, reseñas. Vulnerabilidades de lógica de negocio (precio negativo, descuentos ilimitados, IDOR sobre pedidos ajenos) suelen ser las más impactantes.
• SaaS multi-tenant. Foco en aislamiento entre tenants, autorización por objeto, tokens JWT, gestión de roles, panel de administración. Una mala autorización rompe la promesa fundamental del producto.
• Panel de administración interno. Foco en autenticación, MFA, acceso por VPN, fugas de información en respuestas, capacidad de escalada de privilegios.
• APIs REST, GraphQL, gRPC. Foco en autenticación por endpoint, autorización por objeto y por función, rate limiting, mass assignment, exposición de datos. La especificación OWASP API Security Top 10 es el estándar.
• Single Page Application (SPA) con backend. La frontera entre cliente y servidor importa: cualquier validación crítica que sólo viva en JavaScript es eludible.
• Aplicaciones legacy con varios años en producción. Foco en componentes desactualizados, fugas heredadas, configuraciones antiguas, deuda técnica de seguridad.

Una aplicación moderna mediana suele necesitar una pieza completa de pentesting web una vez al año y un retest tras cada cambio significativo en autenticación, autorización o pagos.

OWASP WSTG y OWASP Top 10: la guía del sector

Los dos estándares que cualquier proveedor profesional sigue son:

• OWASP Web Security Testing Guide (WSTG). La metodología detallada paso a paso, con más de 90 controles repartidos en 12 categorías: recopilación de información, configuración del servidor, gestión de identidad, autenticación, autorización, gestión de sesiones, validación de entrada, manejo de errores, criptografía, lógica de negocio, cliente-side y APIs. Es el manual de referencia que estructura el pentesting.
• OWASP Top 10. La lista de las 10 categorías de vulnerabilidades más críticas en aplicaciones web. La edición 2021 (vigente con actualización en 2025) incluye Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, y Server-Side Request Forgery. Hay un análisis detallado de cada categoría en nuestra entrada OWASP Top 10 2025: vulnerabilidades web más explotadas en empresas.

Un proveedor profesional declara explícitamente que sigue OWASP WSTG y entrega los hallazgos mapeados a OWASP Top 10 + CWE + CVSS para que sean comparables y auditables.

Las fases técnicas de un pentesting web profesional

Un pentesting web competente sigue siempre las mismas seis fases:

1. Preengagement y alcance

Definición escrita de qué se ataca y qué no: dominios, subdominios, endpoints excluidos, ventanas horarias, técnicas permitidas (denegación de servicio: rara vez), credenciales de prueba para cada rol, acuerdos sobre datos sensibles. Sin esta fase firmada, no se empieza.

2. Reconocimiento

Mapeo de la superficie real de la aplicación: subdominios, endpoints ocultos, parámetros, tecnologías, versiones, comportamiento en errores, certificados, fugas en repositorios públicos. Herramientas típicas: subfinder, ffuf, httpx, gau, waybackurls, GitHub dorks.

3. Análisis de la aplicación

Recorrido manual con las credenciales de cada rol, identificación de endpoints sensibles, mapeo del flujo de autenticación, autorización y manejo de sesión. Aquí se construyen las hipótesis de ataque.

4. Explotación

Pruebas activas guiadas por OWASP WSTG: inyección SQL, XSS, IDOR, SSRF, deserialización insegura, abuso de tokens JWT, path traversal, open redirect, race conditions, mass assignment, exposición de información sensible en respuestas, abuso de lógica de negocio. Cada hallazgo se documenta con request, response e impacto.

5. Postexplotación y chaining

Combinación de hallazgos para escalar impacto: una fuga + un IDOR + un SSRF pueden convertirse en una toma de control de la cuenta cloud detrás de la aplicación. Sin esta fase, el informe minimiza el riesgo real.

6. Documentación e informe

Entregable final con resumen ejecutivo, hallazgos detallados (severidad CVSS v3.1, descripción, prueba de concepto, impacto, recomendación), anexos con cadenas de explotación y tabla de mapeo a OWASP Top 10 + CWE. A las semanas, retest opcional para validar que las correcciones aplicadas funcionan.

Vulnerabilidades web más explotadas en 2025-2026

Sin importar el sector o el tamaño de la aplicación, los hallazgos más frecuentes y de mayor impacto que vemos en pentesting web son:

• Broken Access Control. IDOR, escalada horizontal y vertical de privilegios, endpoints administrativos accesibles desde el rol usuario. Sigue siendo la categoría con más impacto medio.
• Inyección SQL y NoSQL en parámetros que no parecían críticos (filtros, búsquedas, exportaciones a CSV).
• Server-Side Request Forgery (SSRF) en funciones que descargan imágenes, generan PDFs, importan URLs o cargan webhooks. Frecuentemente combinable con metadata de cloud (IMDS) para tomar credenciales temporales.
• Cross-Site Scripting (XSS) persistente en CMS y reflejado en parámetros de búsqueda. La explotación con frameworks modernos requiere más creatividad pero la vulnerabilidad sigue presente.
• Vulnerabilidades en componentes desactualizados (librerías frontend, gestores de sesión, frameworks backend con CVEs públicos sin parchear).
• Mala configuración de cabeceras y CORS que permite eludir protecciones del navegador.
• Tokens JWT mal validados (algoritmo none, firma no verificada, claims modificables) que rompen el modelo de autenticación.
• Lógica de negocio rota: precio negativo, cantidad negativa, cupones reutilizables, race conditions en transacciones.

Para profundizar en cada categoría, ver OWASP Top 10 2025: vulnerabilidades web más explotadas en empresas.

Caja blanca, caja negra y caja gris en pentesting web

El modelo de información que se entrega al equipo cambia el resultado:

• Caja negra. Sólo URL pública. El pentester actúa como atacante externo sin contexto. Útil para medir exposición real, ineficiente para encontrar fallos profundos.
• Caja gris. URL más credenciales de cada rol relevante (usuario, administrador, tenant externo). Es el modelo más habitual en pentesting web porque equilibra realismo y eficiencia.
• Caja blanca. URL, credenciales de todos los roles, código fuente y arquitectura. Para máxima cobertura técnica en aplicaciones críticas.

Para una explicación más detallada, ver diferencias entre auditoría caja blanca, negra y gris.

Pentesting web y compliance

Las aplicaciones web son uno de los activos prioritarios para casi todos los marcos:

• NIS2 (artículo 21.2). Pruebas técnicas periódicas como medida obligatoria de gestión de riesgos. Las aplicaciones expuestas son siempre alcance prioritario.
• DORA (Reglamento UE 2022/2554). Pruebas avanzadas y, en entidades designadas, TLPT acreditado bajo TIBER-EU.
• ENS (Real Decreto 311/2022). Pruebas de penetración obligatorias en categorías media y alta, anuales.
• ISO 27001 (control A.8.29). Pruebas técnicas de seguridad sobre sistemas de información.
• PCI DSS v4.0 (req. 11.4). Pentesting de aplicaciones que procesan datos de tarjeta, anual y tras cambios significativos.

Un pentesting web bien diseñado cubre simultáneamente la evidencia técnica para varios marcos. Eso es lo que un proveedor profesional debe articular en la propuesta.

Cómo elegir un proveedor de pentesting web

Cuatro criterios separan un proveedor que aporta valor real de uno que entrega un informe de Burp Scanner pintado de azul:

1. Equipo con experiencia demostrable en aplicaciones web modernas. Pide nombres, certificaciones (OSWE, eWPTX, BSCP, GWAPT) y referencias de aplicaciones similares en sector y stack. Un equipo serio responde sin reparos.

2. Investigación propia y CVEs publicados. Los proveedores que descubren vulnerabilidades en software comercial demuestran capacidad técnica real. En la página de investigación de Secra listamos los CVE descubiertos por nuestro equipo (CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB).

3. Metodología explícita basada en OWASP WSTG. La propuesta debe declarar qué controles del WSTG cubre y cómo. Si el documento no lo dice, probablemente no haya metodología real.

4. Calidad del informe muestra. Pide un informe muestra anonimizado. Mira si los hallazgos están priorizados, si la prueba de concepto es reproducible, si la severidad CVSS está justificada y si la sección ejecutiva habla en términos de negocio.

Algo que no debería ser criterio: el precio más bajo. Un pentesting web low-cost casi siempre significa un escáner automatizado con plantilla genérica. La diferencia se nota cuando llega un incidente.

Cuándo y con qué frecuencia hacer pentesting web

Las cuatro situaciones que disparan un pentesting web:

1. Antes de salir a producción una aplicación nueva o un cambio mayor en autenticación, autorización o pagos.
2. Anualmente como mínimo para mantener evidencia de cumplimiento.
3. Tras un incidente o un near miss para validar que la causa raíz se ha cerrado.
4. Bajo exigencia contractual durante una due diligence o renovación con cliente B2B.

Como heurística rápida: si tu organización publica una aplicación web al exterior, una vez al año es el suelo. Si la aplicación maneja datos regulados (sanitarios, financieros, infraestructura crítica), dos veces al año es más realista.

Preguntas frecuentes

¿Cuánto dura un pentesting web?

Entre 5 y 15 días laborables de ejecución activa según el tamaño de la aplicación, el número de roles y la metodología pactada. El informe llega típicamente 3 a 7 días después del cierre de la fase técnica. El retest (opcional pero recomendado) se ejecuta unas semanas después, una vez aplicadas las correcciones.

¿Qué diferencia hay entre pentesting web y auditoría web?

En la práctica española, los dos términos se usan a menudo como sinónimos cuando se refieren a una prueba ofensiva con alcance acotado sobre una aplicación. La precisión: "auditoría" puede incluir revisión documental y de cumplimiento; "pentesting" se centra en la prueba técnica explotativa. Si vas a contratar, asegúrate de que la propuesta declara metodología (OWASP WSTG) y entrega informe con prueba de concepto.

¿Sirve un escáner automatizado en lugar de un pentesting web?

No. Un escáner detecta vulnerabilidades conocidas a primera vista pero no encadena hallazgos, no abusa de lógica de negocio y no valida explotabilidad real. Es útil como capa continua dentro del CI/CD, pero no sustituye al pentesting manual que un proveedor profesional ejecuta una vez al año.

¿Qué credenciales y accesos hay que dar al pentester?

En modelo caja gris (el más habitual), se entregan credenciales de prueba para cada rol relevante de la aplicación: usuario estándar, usuario premium, administrador, tenant externo, cuenta sin verificar. Estas cuentas suelen apuntar a datos no productivos. Las ROE detallan cómo se gestionan, conservan y destruyen los datos sensibles que aparezcan durante la prueba.

¿El pentesting web puede romper la aplicación?

Un pentesting profesional minimiza el riesgo operativo: ROE escritas, ventanas horarias acordadas, técnicas potencialmente disruptivas excluidas o ejecutadas en preproducción y contactos de emergencia disponibles. El riesgo real no es cero, pero es muy inferior al riesgo de descubrir el fallo cuando lo aprovecha un atacante real.

¿Cómo encaja el pentesting web con el WAF?

Son complementarios. El WAF bloquea ataques conocidos y reduce ruido en los logs, pero no arregla las vulnerabilidades. El pentesting web encuentra los fallos para que se arreglen en el código. Tener WAF sin haber hecho pentesting es defender una puerta sabiendo que el ladrón puede entrar por una ventana abierta que no has revisado.

¿El pentesting web cubre las APIs?

Depende del alcance pactado. Lo habitual en una aplicación moderna es que pentesting web y pentesting de API se contraten conjuntamente, porque el frontend y el backend forman un único sistema desde la perspectiva del atacante. Si tu aplicación es principalmente API (móvil + API, integraciones B2B), conviene un pentesting de API específico siguiendo OWASP API Security Top 10.

¿Qué certificaciones debe tener el equipo que ejecuta el pentesting web?

Las más reconocidas en aplicaciones web son OSWE (Offensive Security Web Expert), eWPTX (eLearnSecurity Web Application Penetration Tester eXtreme), BSCP (Burp Suite Certified Practitioner) y GWAPT (SANS / GIAC Web Application Penetration Tester). Una certificación no garantiza calidad por sí sola, pero su ausencia total en el equipo asignado al proyecto es señal de alarma.

Cómo trabajamos el pentesting web en Secra

En Secra hacemos pentesting web sobre OWASP WSTG con un equipo que publica investigación propia, entrega informes con prueba de concepto reproducible, severidad CVSS justificada y resumen ejecutivo separado del técnico. El alcance se diseña para que la misma prueba sirva como evidencia ante auditorías NIS2, DORA, ENS, ISO 27001 o PCI DSS según aplique. Cuando la aplicación tiene API o app móvil asociadas, el alcance puede ampliarse para cubrir todo el sistema en un único proyecto.

Si quieres una propuesta concreta para tu aplicación, escríbenos a través de contacto o consulta el servicio de auditoría web y móvil. Si lo que buscas es una visión más amplia del pentesting que incluye infraestructura y cloud además de aplicaciones, la lectura previa es nuestra guía completa de pentesting para empresas.