Escáner de vulnerabilidades web: qué detecta, qué se le escapa y cuándo hacer una prueba de penetración
Un escáner de vulnerabilidades web revisa un sitio en minutos en busca de debilidades conocidas. Vea qué detecta, qué requiere a una persona, cómo actuar dentro de la ley y qué corregir primero.
Actualizado el 16 de octubre de 2026
Qué detecta y qué se le escapa a un escáner de vulnerabilidades web
Un escáner automático recorre sus páginas, envía solicitudes y compara las respuestas con patrones de problemas conocidos. Un análisis pasivo solo examina el tráfico normal, y la documentación de ZAP lo considera seguro. Un análisis activo envía solicitudes que imitan ataques, y ZAP advierte (en inglés) que solo debe usarse en aplicaciones que usted tiene permiso para probar.
Los escáneres detectan bien:
- Software con vulnerabilidades conocidas, como un gestor de contenidos, un complemento (plugin) o una biblioteca de JavaScript desactualizados.
- Encabezados de seguridad ausentes y cookies mal configuradas.
- Certificados vencidos y versiones antiguas de TLS.
- Copias de seguridad, listados de directorios y pantallas de administración expuestos.
- Algunos patrones de inyección y de cross-site scripting (XSS) en formularios y parámetros.
También se les escapa mucho. La guía de pruebas de NIST, SP 800-115 (en inglés), señala que los escáneres dan muchos falsos positivos, pasan por alto problemas reales, dependen de firmas actualizadas y necesitan a un experto que interprete los resultados. Espere vacíos en:
- Lógica del negocio: aplicar un cupón dos veces le parece normal a un escáner.
- Acceso entre usuarios: un escáner no puede saber que un cliente no debería ver el pedido de otro.
- Páginas que requieren iniciar sesión, salvo que configure una cuenta de prueba, y procesos de varios pasos.
- Debilidades encadenadas, menores por separado pero graves juntas, y API o subdominios a los que nada enlaza.
Escáner, prueba de penetración de sitios web y evaluación de seguridad
Estos términos se confunden a menudo, y una cotización por uno puede terminar entregando otro.
- Análisis de vulnerabilidades: automático, rápido y repetible. Enumera posibles problemas conocidos en todo el sitio, y una persona todavía debe confirmarlos.
- Prueba de penetración: NIST la describe como pruebas en las que los evaluadores imitan ataques reales para encontrar formas de burlar la seguridad de un sistema. En una prueba de penetración de sitios web, una persona experta combina herramientas con trabajo manual, encadena debilidades y muestra hasta dónde podría llegar un atacante, con un alcance y un plazo definidos, a menudo según la Guía de Pruebas de Seguridad Web de OWASP (en inglés).
- Evaluación de seguridad: una revisión más amplia que puede combinar análisis, revisión de configuración, pruebas y entrevistas en un plan con prioridades.
Un esquema práctico: analice el sitio con regularidad, contrate una prueba de penetración antes de un lanzamiento importante o cuando un contrato lo exija, y use una evaluación para ver el panorama completo.
Obtenga permiso por escrito y defina el alcance primero
Analice solo sitios que le pertenecen o que tiene permiso por escrito para probar. Un análisis activo puede volver lento un sitio, enviar formularios o crear registros basura.
En Estados Unidos, la Ley federal de Fraude y Abuso Informático (CFAA, en inglés) convierte en delito acceder a una computadora sin autorización y permite demandas civiles en algunos casos, y las leyes estatales sobre delitos informáticos son distintas. Que un análisis concreto cruce la línea depende de los hechos y de la jurisdicción; esto no es asesoría legal.
NIST SP 800-115 recomienda un plan de evaluación por escrito. Anote como mínimo:
- Los dominios, subdominios y direcciones IP exactos que entran en el alcance, y lo que queda fuera.
- Quién autorizó el trabajo y cuándo puede hacerse.
- Las técnicas permitidas: solo pasivas, análisis activo o pruebas manuales, con las pruebas de denegación de servicio desactivadas.
- Cómo se manejarán los datos delicados que aparezcan durante las pruebas y a quién llamar si algo falla.
- Terceros. NIST indica que el dueño de otra red normalmente también debe dar su consentimiento por escrito, así que revise la política de pruebas de su proveedor de hosting y deje fuera las páginas de pago y otros servicios que no son suyos.
Si nota un problema en un sitio que no es suyo, deje de probar y repórtelo mediante la política de divulgación de vulnerabilidades del dueño o el contacto de su archivo security.txt (en inglés), que suele estar en /.well-known/security.txt.
Hallazgos comunes al analizar la seguridad de un sitio web
El OWASP Top 10 (en inglés) es la lista de referencia de los riesgos más críticos de las aplicaciones web. Su edición de 2025 empieza por el control de acceso defectuoso, la configuración de seguridad incorrecta, las fallas en la cadena de suministro de software, las fallas criptográficas y la inyección. Entre los resultados típicos:
- Software desactualizado: un gestor de contenidos, complemento, tema o biblioteca con una vulnerabilidad conocida. La CISA señala (en inglés) que muchas actualizaciones existen para corregir riesgos de seguridad; actualice, o quite lo que ya no usa.
- Configuración incorrecta: páginas predeterminadas, listados de directorios, mensajes de error detallados o paneles de administración expuestos.
- Problemas de TLS: certificados vencidos o que no coinciden y versiones antiguas del protocolo. Las pautas de TLS de NIST (en inglés) exigen que los servidores del gobierno de EE. UU. admitan TLS 1.2 y TLS 1.3, una referencia sensata para cualquier sitio.
- Encabezados ausentes: la hoja de referencia de encabezados HTTP de OWASP (en inglés) cubre Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options y Referrer-Policy, y aconseja quitar encabezados como X-Powered-By que revelan detalles del software.
- Inyección y cross-site scripting: datos que llegan a una consulta de base de datos o a una página sin el tratamiento adecuado.
- Sesiones: cookies sin los indicadores Secure o HttpOnly, o sesiones que nunca vencen.
Opciones gratuitas de escáner de vulnerabilidades web
Cada opción gratuita necesita que alguien la configure con cuidado y lea los resultados.
- ZAP: el proyecto ZAP (en inglés) ofrece un escáner de aplicaciones web gratuito y de código abierto. Su análisis básico (baseline scan) recorre un sitio durante un minuto aproximadamente e informa hallazgos pasivos sin realizar ataques reales.
- Lista de herramientas de OWASP: la página Vulnerability Scanning Tools (en inglés) reúne escáneres de código abierto, gratuitos y comerciales; OWASP aclara que aparecer en la lista no es una recomendación.
- Mozilla HTTP Observatory: el HTTP Observatory (en inglés) evalúa los encabezados HTTP de un sitio y otras configuraciones clave de seguridad.
- Cyber Hygiene de la CISA: los servicios de análisis de vulnerabilidades y de aplicaciones web (en inglés) de la CISA no tienen costo para gobiernos federales, estatales, locales, tribales y territoriales de EE. UU., y para organizaciones públicas y privadas de infraestructura crítica.
Cómo leer los resultados y decidir qué corregir primero
- Confirme el hallazgo. Revise la versión reportada, reproduzca el problema en una copia de prueba si puede y anote por qué descartó cada falso positivo.
- Use la gravedad como punto de partida. Muchos informes usan puntuaciones CVSS (en inglés) de FIRST, hoy en la versión 4.0, que reflejan la gravedad. NIST aconseja que los evaluadores juzguen el riesgo real en lugar de aceptar sin más la calificación del escáner.
- Verifique si se está explotando. Un CVE que aparece en el catálogo de vulnerabilidades explotadas conocidas (KEV, en inglés) de la CISA ya se ha explotado en ataques reales, y la CISA recomienda usar el catálogo como un dato para priorizar.
- Considere la exposición y los datos. Una falla en una página pública de inicio de sesión o de pago pesa más que una en una página informativa estática.
- Agrupe por causa. Un complemento desactualizado puede generar una docena de hallazgos.
- Asigne un responsable y una fecha a cada corrección y vuelva a analizar para confirmar que funcionó.
Con qué frecuencia analizar la seguridad de su sitio web
No hay un calendario único para todos los sitios. NIST señala que una evaluación es una foto de un momento dado y que la frecuencia suele depender de requisitos de cumplimiento. Una base razonable para un sitio pequeño:
- Después de cada cambio importante, como un complemento nuevo, una actualización de la plataforma o un cambio de hosting.
- Con un calendario fijo, por ejemplo mensual, más un análisis pasivo básico después de cada publicación.
- Un análisis autenticado más completo o una prueba de penetración al menos una vez al año y antes de lanzamientos importantes.
- Si acepta pagos con tarjeta, el requisito 11.3.2 de PCI DSS pide análisis externos aprobados, hechos por un proveedor de análisis aprobado (ASV), al menos una vez cada tres meses, según el PCI Security Standards Council (en inglés). Pregunte a su proveedor de pagos qué se aplica a su caso.
Qué preguntar antes de contratar servicios de evaluación de seguridad
Ya sea que contrate una prueba de penetración o una evaluación más amplia, pida las respuestas por escrito:
- Alcance: ¿quedarán los objetivos, las exclusiones, las fechas y las técnicas permitidas en un documento firmado antes de empezar?
- Método: ¿qué metodología siguen y cuánto del trabajo es manual, y no un informe de escáner con otra portada?
- Personas: ¿quién hace las pruebas, con qué experiencia, y se subcontrata alguna parte?
- Seguridad: ¿cómo evitan afectar el sitio en producción y quién puede detener la prueba?
- Datos: ¿qué recopilan, dónde lo guardan y cuándo lo eliminan?
- Informe: ¿cada hallazgo incluirá evidencia, pasos para reproducirlo, el razonamiento de su gravedad y una corrección concreta?
- Nueva prueba y precio: ¿incluye una nueva prueba de lo corregido y qué cambiaría la cotización?
Desconfíe de quien garantice que un sitio no puede ser vulnerado.
Dónde encaja ASL Scan
ASL Scan no es un escáner de autoservicio que se apunta a una URL. ASL lo ofrece como una evaluación autorizada para proveedores de servicios administrados, consultores de seguridad y responsables de informática, y un analista revisa cada informe antes de que llegue al cliente. Una autorización firmada indica los equipos exactos, las plataformas, quién aprueba y la fecha de vencimiento, y la revisión rechaza todo lo que quede fuera.
Su revisión de solo lectura se ejecuta en equipos con Windows y Linux, mide 35 controles de endurecimiento, como el firewall, el cifrado del disco y el acceso remoto, y señala 16 puertos de servicios sensibles. Cada control da aprobado, fallido, desconocido o no aplicable, y un desconocido nunca cuenta como aprobado. Los resultados se sellan con una huella que revela alteraciones. La página del producto también menciona un paquete de evaluación web autorizada de 150 controles.
Límites: no es una certificación de cumplimiento, y aprobar una revisión no demuestra que un sistema esté libre de fallas. No hay portal para clientes: usted recibe el informe revisado y el paquete de evidencia sellado. Su nivel más intenso de ataque activo es solo para sistemas desechables aprobados por su dueño. El precio se cotiza por proyecto. Conozca cómo funciona ASL Scan.
Preguntas frecuentes
¿Es legal analizar un sitio web en busca de vulnerabilidades?
Analizar su propio sitio, o uno que tiene permiso por escrito para probar, es una práctica normal. Analizar el sitio de otra persona sin permiso puede exponerlo a responsabilidad penal o civil según las leyes federales y estatales sobre delitos informáticos, que varían de un estado a otro.
¿En qué se diferencia un escáner de vulnerabilidades web de una prueba de penetración de sitios web?
El escáner busca de forma automática debilidades conocidas, y una persona debe confirmar los resultados. La prueba de penetración la dirige una persona que imita a un atacante, combina debilidades y muestra el impacto real dentro de un alcance acordado.
¿Basta con un escáner de vulnerabilidades web gratuito?
Para problemas conocidos en su propio sitio puede bastar, si alguien lo configura bien y lee los resultados con criterio. No reemplaza una prueba humana de los inicios de sesión, los permisos y la lógica del negocio.
¿Con qué frecuencia debo analizar la seguridad de mi sitio web?
Después de cada cambio importante y con un calendario fijo, por ejemplo mensual. Los sitios que aceptan pagos con tarjeta también pueden tener requisitos de PCI DSS, incluidos análisis aprobados por un ASV al menos cada tres meses.
¿Un análisis de vulnerabilidades puede tumbar mi sitio web?
Un análisis activo puede hacerlo; NIST señala que el tráfico de análisis puede afectar a los sistemas analizados. Empiece con un análisis pasivo, use una copia de prueba cuando pueda y desactive las pruebas de denegación de servicio.
Guías relacionadas
- Checklist de auditoría web: qué revisar y qué corregir primero
- ¿Qué es un sistema de detección de intrusos (IDS)?
- Ejemplo de evidencia y control de ASL Scan