Acunetix Web Vulnerability Scanner (WVS) es un escáner DAST para detectar vulnerabilidades en aplicaciones web y servicios HTTP(S) sin necesidad de acceder al código fuente. En 2026 se usa sobre todo en flujos de pentesting, auditorías de seguridad y DevSecOps para encontrar fallos repetibles (y con evidencia) antes de que lleguen a producción. Algunas capacidades pueden variar por edición/plan, así que conviene validar qué incluye tu licencia en la documentación oficial.
Importante: escanea únicamente sitios que te pertenezcan o para los que tengas autorización explícita. Un escaneo puede generar carga, alertas de WAF/CDN y registros de intentos de explotación.
Cómo usarlo paso a paso (la forma más rápida)
Define el alcance: anota el dominio/URL base, subdominios permitidos y rutas “fuera de scope”. Si es posible, escanea primero un entorno staging.
Accede a la plataforma: instala la versión local (Windows/Linux/Docker, según edición) o ingresa al panel web si usas la variante en la nube (cuando aplique).
Crea un “Target”: carga la URL inicial y confirma que responde por https y que el certificado es válido (para evitar falsos negativos por bloqueo TLS).
Elige el tipo de escaneo: comienza con un perfil “rápido” para mapa inicial y luego pasa a un escaneo completo para profundidad (crawling + pruebas activas).
Configura autenticación si hay login: para áreas privadas, prepara un método de inicio de sesión (formulario, cabeceras, cookies o secuencia grabada) y una URL de verificación post-login.
Controla el impacto: limita concurrencia y velocidad si el sitio es sensible. En sitios con protección anti-bots, considera una ventana de mantenimiento.
Ejecuta el escaneo y revisa el crawling: si el rastreo no encuentra rutas, ajusta el alcance, añade rutas manuales o importa definiciones de API cuando corresponda.
Triaguea hallazgos: prioriza por criticidad y “evidencia reproducible”. Clasifica falsos positivos y abre tickets solo con pasos claros para replicación.
Corrige y re-escanea: valida que el fix elimina la causa (no solo el síntoma) y repite el escaneo en la misma configuración para comparar resultados.
Acunetix apunta a vulnerabilidades típicas de aplicaciones web y configuraciones inseguras. El valor real no es “la lista”, sino la combinación de prueba activa + evidencia que permite reproducir el problema y corregirlo con precisión.
Hallazgos frecuentes en aplicaciones web
Inyección: SQLi, inyección de comandos y variantes que dependen de validación de entrada y contexto.
XSS y fallos del lado cliente: especialmente en apps modernas con mucho JavaScript, donde el DOM y las rutas dinámicas complican el rastreo.
Autenticación/sesión: cookies inseguras, cabeceras faltantes, exposición de endpoints, tokens mal gestionados o controles débiles.
Configuración: encabezados de seguridad ausentes, CORS demasiado permisivo, directorios listados o componentes expuestos.
Cómo priorizar sin perder tiempo
Primero: vulnerabilidades con explotación directa y evidencia clara (payload reproducible, endpoint y parámetro identificados).
Segundo: fallos de autenticación/autorización y exposición de datos, porque suelen ser de alto impacto aunque no “rompan” la app.
Tercero: hardening y mejoras preventivas (cabeceras, TLS, configuración). Son rápidas y reducen superficie de ataque.
Qué debería incluir un ticket “usable”
URL exacta y método (GET/POST), parámetro afectado, cabeceras relevantes.
Paso a paso para reproducir (idealmente con request/response resumidos).
Impacto técnico en una frase (qué puede lograr un atacante) y propuesta de mitigación.
Configuración clave para mejores resultados en sitios con login, SPA y APIs
El punto donde más escáneres fallan es el acceso a zonas privadas y el descubrimiento de rutas en aplicaciones modernas. Si el rastreo no “ve” la app, los resultados se vuelven incompletos.
Escaneo autenticado (áreas privadas)
Causa típica de cobertura baja: el escáner no mantiene sesión o no supera el flujo de autenticación (MFA, CAPTCHA, tokens rotativos).
Enfoque práctico: define una URL de “estado autenticado” (por ejemplo, /account o /dashboard) y úsala como verificación. Si el panel vuelve a /login, la sesión no quedó activa.
Señal de éxito: el crawling comienza a descubrir rutas internas que no aparecen sin login y el conteo de URLs aumenta de forma consistente.
SPA y JavaScript pesado
Problema típico: rutas que se cargan por XHR/fetch y no por navegación clásica.
Solución práctica: valida que el escaneo use un motor capaz de ejecutar JavaScript y que el sitio no bloquee el headless browser. Si la app depende de eventos, considera añadir rutas manuales como punto de entrada.
Qué comprobar: si el reporte muestra rutas generadas por navegación dinámica y requests XHR relevantes, la cobertura está mejorando.
APIs (Swagger/OpenAPI y endpoints “no navegables”)
Problema típico: endpoints que no están enlazados desde la UI y nunca se descubren por crawling.
Solución práctica: cuando exista, importa una definición OpenAPI/Swagger o añade rutas/endpoints conocidos para que el escáner pruebe parámetros y respuestas.
Qué comprobar: que el escaneo liste endpoints del contrato y los incluya en el análisis activo.
Para configuraciones específicas (login, importación de definiciones, ajuste de crawling y alcance), apóyate en la documentación oficial: guías y configuración de escaneos en Acunetix.
Problemas comunes y soluciones rápidas
No encuentra URLs o escanea “muy poco”
Causa probable: el crawling está limitado por alcance, redirecciones, bloqueo por robots/anti-bot o la app es una SPA sin rutas navegables clásicas.
Solución rápida: revisa el alcance, añade rutas iniciales manuales y, si aplica, importa endpoints de API o define un punto de entrada autenticado.
Qué comprobar: el conteo de URLs descubiertas aumenta y aparecen rutas profundas (no solo la home).
El login falla y no entra a zonas privadas
Causa probable: MFA/CAPTCHA, tokens que rotan, cookies no persistentes o la secuencia de login no está bien definida.
Solución rápida: configura un método de autenticación soportado, define una URL de verificación post-login y evita flujos que requieran interacción humana (cuando sea posible en staging).
Qué comprobar: durante el escaneo, la app permanece autenticada y se rastrean rutas del panel privado.
Demasiados falsos positivos
Causa probable: respuestas genéricas del servidor, WAF devolviendo páginas estándar, o reglas demasiado agresivas para el contexto.
Solución rápida: valida con evidencia (request/response), ajusta el perfil de escaneo, marca hallazgos como no reproducibles y vuelve a escanear con parámetros más precisos.
Qué comprobar: baja el volumen de hallazgos “duplicados” y aumenta la tasa de reproducciones exitosas.
El sitio bloquea el escaneo (403/429/anti-bot)
Causa probable: rate limiting, WAF/CDN, reglas anti-automatización o bloqueo por patrón de requests.
Solución rápida: reduce concurrencia, ajusta la velocidad del escaneo, coordina una ventana de pruebas y (si corresponde) permite la IP del escáner en el WAF.
Qué comprobar: disminuyen los 403/429 y el crawling vuelve a descubrir rutas de forma estable.
El escaneo tarda demasiado o se queda “colgado”
Causa probable: sitio grande, respuestas lentas, timeouts conservadores o recursos del servidor del escáner insuficientes.
Solución rápida: acota alcance por secciones, usa un escaneo inicial rápido, ajusta timeouts y ejecuta en un equipo/servidor con recursos adecuados.
Qué comprobar: el progreso avanza por módulos y el escaneo finaliza con reporte exportable.
No coincide el hallazgo con el comportamiento real
Causa probable: entorno distinto (staging vs producción), caché/CDN, rutas protegidas por roles o cambios entre builds.
Solución rápida: fija el entorno objetivo, registra versión/build, y reproduce el hallazgo con el mismo usuario/rol del escaneo.
Qué comprobar: la reproducción manual coincide con el reporte o el hallazgo se descarta con justificación.
Preguntas frecuentes
¿Acunetix sirve si no tengo acceso al código fuente?
Sí. Al ser un enfoque DAST, prueba la aplicación desde afuera (como un atacante) y reporta evidencia a nivel HTTP. Aun así, para corregir más rápido, conviene que el equipo dev pueda ver logs y trazar el endpoint afectado.
¿Puedo usarlo en producción sin riesgo?
Depende del tamaño del sitio y de tus límites de tolerancia a carga/alertas. En producción se recomienda empezar con perfiles conservadores, baja concurrencia y una ventana controlada. Para máxima seguridad operativa, lo ideal es staging con datos no sensibles.
¿Detecta SQL injection y XSS de forma confiable?
Puede detectarlas con evidencia, pero la calidad final depende de la cobertura (crawling), autenticación y del comportamiento de la app/WAF. Si el sitio devuelve respuestas genéricas o bloquea pruebas, aumenta el riesgo de falsos positivos o cobertura incompleta.
¿Cómo escaneo zonas con login y roles?
Configura un método de autenticación y valida el acceso con una URL post-login. Si hay roles distintos (usuario, admin, etc.), lo normal es ejecutar escaneos separados por rol para cubrir endpoints que solo aparecen con permisos específicos.
¿Se puede escanear una API aunque no tenga interfaz web?
En muchos escenarios, la cobertura mejora si importas definiciones OpenAPI/Swagger o agregas endpoints conocidos para que el escáner pruebe parámetros y respuestas. Revisa en la documentación de tu edición el método recomendado para APIs y contratos.
¿Cada cuánto conviene escanear?
Como mínimo, después de cambios relevantes (deploys, nuevas rutas, librerías, cambios de autenticación). En DevSecOps, lo ideal es un escaneo recurrente programado y escaneos bajo demanda para releases críticos.
Si necesitas un enfoque práctico, empieza por un escaneo rápido para descubrir superficie, configura autenticación para cubrir áreas privadas y luego ejecuta un escaneo completo con el alcance bien definido. Después, prioriza hallazgos reproducibles y re-escanea tras cada corrección para cerrar el ciclo. Para reforzar contexto técnico, puedes revisar qué fue Log4j y cómo mantenerte a salvo, entender mejor cómo funciona un servidor web y, si necesitas un entorno de pruebas aislado, ver opciones de servidores VPS gratis para laboratorio.
Periodista argentino especializado en tecnología aplicada, finanzas digitales y medios de pago. Me dedico a analizar herramientas online, billeteras virtuales y trámites complejos para transformarlos en guías simples. Mi objetivo es ayudarte a tomar mejores decisiones con tu dinero y tu tiempo, desde configurar Windows hasta optimizar tus finanzas.
La información de este artículo se elaboró a partir de la experiencia práctica del autor
y de la consulta de fuentes oficiales, documentación de las plataformas y material técnico
disponible al momento de la última actualización.
Intento que los contenidos sean lo más exactos y actuales posible, pero algunas condiciones
pueden cambiar con el tiempo (precios, comisiones, menús de las aplicaciones, políticas de
servicio, requisitos de trámites, etc.). Por eso, siempre es recomendable verificar los
datos directamente en los sitios oficiales, centros de ayuda o soporte de cada servicio.
Importante: este contenido tiene fines exclusivamente
informativos y educativos y no sustituye el asesoramiento profesional
personalizado (financiero, legal, médico o técnico especializado). Antes de tomar decisiones
que puedan afectar tu dinero, tu salud, tus datos o tu situación legal, consultá con un
profesional matriculado o con el soporte oficial correspondiente.
