Pruebas de seguridad en sitios web: pentesting aplicaciones web explicado

Un sitio web corporativo es hoy un activo crítico: procesa pagos, almacena datos de clientes y expone lógica de negocio a cualquier usuario con un navegador. Cuando se publica una nueva versión sin pruebas de seguridad reales, el riesgo no es teórico: es un incidente esperando su turno. Las pruebas de penetración web (pentesting) son el mecanismo técnico para encontrar esas fallas antes que un atacante.

El problema recurrente en empresas de LATAM es confundir un escaneo automatizado con un pentest profesional. El primero da un PDF con cientos de hallazgos, muchos falsos positivos y ninguna prueba de explotabilidad. El segundo entrega evidencia de impacto real: qué dato se extrajo, qué privilegio se escaló y qué cadena de ataque fue viable en producción.

Esta guía explica qué es pentesting de aplicaciones web, cómo se diferencia de un scanner, los tipos y metodologías estándar, la cadencia recomendada y qué debe contener un reporte que sirva al negocio y no solo al equipo técnico.

Qué es pentesting vs vulnerability scanning

El vulnerability scanning es un proceso automatizado que compara su aplicación contra una base de firmas conocidas (CVE, configuraciones inseguras, versiones desactualizadas). Se ejecuta rápido, es barato y escala bien, pero no valida explotabilidad ni entiende la lógica de negocio. Un scanner no sabe que un usuario rol "vendedor" no debería acceder al endpoint /admin/reports.

El pentesting es una prueba manual (asistida por herramientas) donde un especialista simula un atacante real. Encadena vulnerabilidades, abusa lógica de negocio, evade controles y demuestra impacto. Según [VERIFICAR: porcentaje de hallazgos críticos que requieren análisis manual según OWASP 2025], una porción mayoritaria de los hallazgos de alto riesgo en aplicaciones web no es detectable por herramientas automatizadas.

La regla práctica: el scanning es un control continuo (semanal o mensual), el pentesting es un ejercicio profundo (trimestral o por release mayor). No son sustitutos. Si quiere el marco completo de controles, revise nuestra guía de ciberseguridad empresarial 2026.

Los 5 tipos: black/grey/white box, red team, bug bounty

Cada modalidad responde a una pregunta distinta sobre el riesgo.

• Black box: el pentester no recibe información interna. Simula un atacante externo sin credenciales. Útil para medir exposición pública, pero limitado en cobertura porque buena parte de la aplicación queda detrás del login.
• Grey box: se entregan credenciales de usuario estándar y, opcionalmente, documentación básica. Es la modalidad más costo-eficiente para aplicaciones web: cubre lógica autenticada, IDOR, escalamiento horizontal y vertical.
• White box: acceso completo a código fuente, arquitectura y credenciales administrativas. Máxima cobertura, ideal para componentes críticos (pasarelas de pago, módulos de autenticación).
• Red team: ejercicio multi-vector (web, phishing, físico, wireless) contra objetivos de negocio definidos (exfiltrar base de clientes, llegar al dominio). No es un pentest web, es una simulación de adversario completo.
• Bug bounty: programa continuo con investigadores externos que reportan hallazgos a cambio de recompensas. Complementa el pentest formal, no lo reemplaza, porque no hay garantía de cobertura.

Para la mayoría de sitios transaccionales en LATAM, grey box con cadencia trimestral es el punto óptimo entre costo y profundidad.

Metodologías: OWASP Testing Guide, PTES, NIST

Un pentest sin metodología es un ejercicio artístico, no auditable. Tres estándares dominan el mercado:

OWASP Web Security Testing Guide (WSTG): la referencia específica para aplicaciones web. Cubre más de 90 casos de prueba organizados por categorías (autenticación, gestión de sesiones, validación de entrada, criptografía, lógica de negocio, API). Es la base operativa del 80% de los pentest web serios.

PTES (Penetration Testing Execution Standard): define las siete fases del proceso completo, desde pre-engagement hasta reporting. Aporta la estructura contractual y de comunicación con el cliente: cómo se pacta alcance, reglas de engagement y criterios de éxito.

NIST SP 800-115: guía técnica del gobierno de EE.UU. Es menos prescriptiva que OWASP pero útil cuando se necesita alinear con marcos regulatorios (HIPAA, FedRAMP) o subsidiarias en USA.

En la práctica, un proveedor competente combina las tres: PTES para el proceso, OWASP WSTG para la ejecución técnica web y NIST como referencia para clientes con requisitos regulatorios.

Cuándo y con qué frecuencia

La cadencia depende del perfil de riesgo y del ritmo de cambio del producto. Tres disparadores obligan a un pentest:

1. Antes de ir a producción con una aplicación nueva o un rediseño mayor.
2. Después de cambios significativos: nuevo módulo de pagos, migración de infraestructura, integración con API externas, cambios en el modelo de autenticación.
3. Cumplimiento regulatorio: PCI DSS exige pentest al menos anual y tras cambios significativos [VERIFICAR: requisito exacto PCI DSS 4.0 sección 11.4]. ISO 27001 y SOC 2 también lo demandan como evidencia de control.

Como línea base para un SaaS B2B con releases frecuentes: pentest anual completo, retest trimestral focalizado y scanning automatizado continuo en CI/CD. Para entender qué vectores se priorizan, conviene revisar los ciberataques más frecuentes en sitios web.

Herramientas: Burp Suite, OWASP ZAP, Metasploit

El pentester trabaja con un stack, no con una sola herramienta. Las tres más relevantes para web:

Herramienta	Uso principal	Perfil
Burp Suite Professional	Proxy de interceptación, scanner activo, fuzzing, extensiones	Estándar de facto en pentest web comercial
OWASP ZAP	Proxy, escaneo automatizado, integración CI/CD	Open source, ideal para DAST continuo
Metasploit Framework	Explotación de vulnerabilidades conocidas, post-explotación	Más usado en infra que en web, pero útil en cadenas de ataque

Herramientas complementarias en un pentest web típico: sqlmap (inyección SQL), ffuf o gobuster (descubrimiento de rutas), nuclei (plantillas de vulnerabilidades), Postman o mitmproxy (APIs). El valor no está en la herramienta sino en la hipótesis de ataque que el especialista construye y verifica.

Qué esperar del reporte

Un reporte de pentest que sirve al negocio tiene siete componentes no negociables:

1. Resumen ejecutivo de una página: nivel de riesgo global, hallazgos críticos, impacto potencial en negocio. Sin jerga.
2. Alcance y metodología: qué se probó, qué quedó fuera, qué estándares se aplicaron.
3. Hallazgos detallados: cada vulnerabilidad con descripción, evidencia reproducible (requests, screenshots), severidad CVSS 3.1, impacto de negocio y recomendación específica.
4. Cadenas de ataque: cómo se combinaron hallazgos menores para lograr impacto crítico. Esto diferencia un pentest real de un scan.
5. Plan de remediación priorizado: qué corregir primero según esfuerzo vs reducción de riesgo.
6. Retest incluido: verificación de que las correcciones cerraron el hallazgo, con nuevo anexo al reporte.
7. Evidencia de cumplimiento: mapeo contra el marco regulatorio aplicable (PCI, ISO 27001, SOC 2).

Si el entregable es un export de Nessus con cambio de logo, exija reembolso. Y si su foco adicional es experiencia de usuario y cumplimiento, considere también accesibilidad WCAG como parte del mismo ciclo de calidad.

Próximo paso

Si su aplicación web procesa pagos, datos personales o información regulada y no ha tenido un pentest en los últimos 12 meses, el riesgo es material. Contáctanos para un diagnóstico de 30 minutos donde evaluamos su superficie de ataque, cadencia recomendada y alcance óptimo.

Preguntas frecuentes

¿Cuánto cuesta un pentest de aplicación web?

El rango típico en LATAM para una aplicación web de complejidad media (grey box, 1–2 semanas) va de USD 8.000 a USD 25.000 [VERIFICAR: rango de precios pentest web LATAM 2026]. Varía según cantidad de roles, endpoints, APIs y profundidad metodológica.

¿Un pentest tumba la aplicación en producción?

Un pentest profesional se coordina con reglas de engagement que incluyen ventanas de prueba, límites de rate y exclusión de payloads destructivos. Lo recomendable es ejecutar en staging con paridad de datos, y solo validar hallazgos críticos en producción con autorización explícita.

¿Pentest interno o externo?

Equipo interno aporta contexto de negocio y continuidad. Proveedor externo aporta mirada fresca, especialización y es requisito en varios marcos regulatorios (PCI DSS exige independencia del tester respecto al equipo que desarrolló el componente).

¿Qué diferencia un pentest de una auditoría de seguridad?

La auditoría revisa políticas, procesos y controles contra un estándar (ISO 27001, SOC 2). El pentest es una prueba técnica ofensiva que valida si los controles funcionan en la práctica. Son complementarios.

¿Cada cuánto se debe hacer pentest si el producto cambia semanalmente?

Pentest completo anual, retest focalizado trimestral sobre módulos modificados, y DAST/SAST automatizado en cada release dentro del pipeline CI/CD. Así se cubre ritmo de cambio sin explotar el presupuesto.

¿El pentest cubre también las APIs?

Debe cubrirlas. Hoy las APIs (REST, GraphQL) concentran buena parte de la superficie de ataque y tienen su propia lista OWASP API Security Top 10. Si el alcance propuesto no las menciona explícitamente, solicite incluirlas.