Qué debería cubrir un pentesting web y qué no
Un pentesting web no es un escaneo genérico sobre una URL. El valor aparece cuando la prueba intenta comportarse como un atacante real dentro del alcance acordado: autenticación, perfiles, flujos críticos, archivos, exposición de datos, controles de sesión y lógica de negocio.
Lo importante no es “que se corran herramientas”, sino que exista criterio técnico sobre qué atacar primero y cómo priorizar lo que realmente pondría en riesgo a la empresa. Si el sitio tiene cuentas de usuario, roles, pagos, paneles internos o integraciones, el pentest debe mirar esos puntos y no quedarse solo en el homepage.
Reconocimiento, validación manual, explotación controlada, evidencia y priorización de remediación.
Arquitectura segura, monitoreo continuo ni gestión de vulnerabilidades permanente.
Si una propuesta promete un pentest “rápido” sin pedir credenciales, roles, endpoints ni contexto del negocio, probablemente te está vendiendo cobertura aparente, no profundidad real.
Qué se revisa en una aplicación web empresarial
La revisión técnica cambia según el tipo de aplicación, pero hay áreas que suelen concentrar la mayor parte del riesgo en entornos corporativos.
Flujos de login, recuperación de contraseña, MFA, fuerza bruta, sesiones y persistencia indebida.
Escalada de privilegios, acceso a recursos de otros usuarios y separación deficiente entre roles.
Validación de parámetros, carga de archivos, inyección, traversal y abuso de formularios o reportes.
Saltarse pasos, alterar montos, repetir acciones críticas o abusar de workflows que el sistema asume como válidos.
En empresas, esta última capa suele ser la más importante. Un hallazgo crítico no siempre es una vulnerabilidad “clásica”; a veces es un flujo que permite aprobar, descargar o modificar algo que nunca debió quedar expuesto. Ahí es donde el pentesting se conecta con una estrategia más amplia de ciberseguridad para empresas.
Los entregables que marcan la diferencia
La utilidad del servicio no termina en “encontramos tres vulnerabilidades”. Un buen pentest deja material accionable para tecnología, gestión y eventualmente terceros que piden evidencia.
| Entregable | Para qué sirve | Qué revisar |
|---|---|---|
| Resumen ejecutivo | Explicar impacto de negocio y riesgo general | Lenguaje claro, prioridades y exposición real |
| Reporte técnico | Guiar la corrección del equipo interno o proveedor | Evidencia, pasos de reproducción y remediación concreta |
| Sesión de cierre | Alinear dudas y ordenar el plan de trabajo | Priorización, quick wins y dependencias |
| Re-test | Confirmar que las correcciones redujeron el riesgo | Qué hallazgos fueron revalidados y cuáles siguen abiertos |
Si el reporte solo enumera hallazgos sin contexto, el equipo pierde tiempo traduciendo severidad técnica a urgencia de negocio. Si además no existe revalidación, se corre el riesgo de cerrar tickets sin confirmar que el problema realmente desapareció.
Cuánto tarda un pentesting web en la práctica
No hay una duración única. Lo que más mueve el tiempo es el tamaño de la superficie, la cantidad de roles, la criticidad de los flujos y si el entorno es estable para probar.
- Una aplicación acotada con uno o dos roles suele resolverse en pocos días efectivos.
- Portales con más workflows, integraciones o módulos críticos tienden a irse a una o más semanas.
- El tiempo total del proyecto también considera preparación, ventana de pruebas, reporte y cierre.
- Si hay hallazgos críticos, la comunicación relevante debe salir antes del informe final.
La pregunta útil no es solo “cuánto dura”, sino “qué profundidad de revisión cabe en ese tiempo”. Dos propuestas con la misma fecha de entrega pueden ser servicios radicalmente distintos.
Cómo preparar el pentesting para que sí sirva
La mejor forma de bajar fricción es ordenar contexto antes de empezar. Eso evita perder tiempo explicando el entorno a mitad de la prueba y reduce ruido operativo.
- Define URLs, ambientes, IPs y componentes que sí entran en alcance.
- Prepara usuarios de prueba por rol y explica los flujos críticos del negocio.
- Aclara ventanas horarias y restricciones operativas si el sistema es sensible.
- Identifica integraciones externas o dependencias que podrían afectar la prueba.
- Decide desde el inicio quién recibirá hallazgos críticos y quién prioriza correcciones.
Si el sistema además tiene exposición a ransomware, hardening pendiente o presión regulatoria, conviene combinar esta validación ofensiva con una mirada más amplia como la que planteamos en esta guía sobre ransomware en Chile.
Cuándo conviene hacerlo y cuándo ya vas tarde
El mejor momento para un pentest es antes de una exposición relevante: salida a producción, onboarding de clientes enterprise, integración crítica o cierre de una etapa grande de desarrollo. Esperar a que lo pida un cliente no siempre es fatal, pero suele dejar menos margen para corregir bien.
- Conviene hacerlo antes de publicar nuevos módulos con autenticación o datos sensibles.
- Conviene repetirlo cuando hubo cambios importantes en el sistema o la infraestructura.
- Conviene usarlo para validar correcciones tras incidentes o hallazgos internos.
- Ya vas tarde si el sistema procesa información crítica y nunca fue probado con enfoque ofensivo.
Si tu empresa necesita una evaluación concreta sobre web, APIs o red, esta guía es solo el punto de partida. El servicio correcto es el que aterriza alcance, riesgos y entregables a tu plataforma real.