Prueba de seguridad del servidor web: Lista de verificación completa

Una prueba de seguridad de un servidor web verifica nueve aspectos: la configuración del protocolo y el cifrado TLS, la validez del certificado, los encabezados de seguridad HTTP, la Content Security Policy, los atributos de las cookies, la divulgación de la versión del software, las vulnerabilidades conocidas en el servidor y el CMS, la configuración de DNSSEC y los servicios y métodos expuestos innecesariamente. La mayoría de estos aspectos se pueden verificar de forma gratuita en menos de un minuto desde un navegador, y todos ellos son problemas de configuración, lo que significa que son corregibles sin tocar el código de la aplicación.

Las vulnerabilidades de las aplicaciones captan la atención, pero una gran parte de la exposición en el mundo real se debe simplemente a la configuración del servidor: una versión obsoleta de TLS aún habilitada, un encabezado Server que anuncia la versión exacta, una cookie de sesión sin el flag Secure, ausencia total de Content Security Policy. Ninguna de estas requiere un bug en tu código. Todas son visibles desde el exterior, lo que significa que un atacante las ve antes que tú.

La ventaja es que los problemas de configuración son fáciles de corregir. Esta lista de comprobación cubre qué probar, por qué cada elemento importa y cómo verificarlo sin instalar nada.

Lista de comprobación de seguridad de servidor web

Protocolos TLS y cipher suites

SSL 3.0, TLS 1.0 y TLS 1.1 están obsoletos y deben desactivarse por completo. TLS 1.2 con conjuntos de cifrado modernos es el mínimo exigido, TLS 1.3 es el objetivo. Los conjuntos de cifrado deben proporcionar forward secrecy, para que un futuro compromiso de la clave privada no descifre retroactivamente el tráfico capturado.

Elementos específicos a eliminar: RC4, 3DES, cifrados de grado de exportación, cualquier mecanismo con intercambio de claves NULL o anónimo, y suites en modo CBC donde exista una alternativa moderna.

Vale la pena añadir a la lista en 2026: preparación post-cuántica. El tráfico cifrado capturado hoy puede almacenarse y descifrarse más adelante, una vez que los ordenadores cuánticos sean capaces, lo que lo convierte en una preocupación actual para cualquier activo con un horizonte de confidencialidad largo.

Comprueba todo esto con el SSL Security Test gratuito, que cubre servidores web y de correo electrónico e informa sobre la preparación para la criptografía poscuántica y el cumplimiento de PCI DSS, GDPR, HIPAA y NIST.

2. Validez y cadena del certificado

Tres modos de fallo explican casi todos los incidentes de certificados. El certificado expira, normalmente en un host que nadie recordaba que estaba en alcance. La cadena intermedia está incompleta, por lo que funciona en un navegador de escritorio que almacena en caché los intermedios, pero falla en dispositivos móviles y en clientes de API. O bien el certificado no cubre el nombre de host realmente utilizado, típicamente un «www» o un nuevo subdominio.

Los tres son invisibles hasta que fallan. El monitoreo continuo es la única solución real, ya que un certificado que hoy es válido caduca en una fecha que nadie rastrea.

3. HTTP Strict Transport Security

HSTS indica a los navegadores que rechacen el HTTP plano para tu dominio por completo. Sin él, la primera solicitud de un usuario puede ser interceptada y degradada antes de que se ejecute tu redirección a HTTPS.

Un encabezado de producción adecuado:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Añade «includeSubDomains» solo cuando estés seguro de que cada subdominio sirve HTTPS, y trata «preload» como una puerta unidireccional, ya que la retirada de la lista de «preload» es lenta.

4. Content Security Policy

CSP es el encabezado más eficaz contra cross-site scripting y web skimming, y también el que con mayor frecuencia falta, ya que redactar una política que no rompa el sitio requiere esfuerzo real.

Una política solo es tan buena como su strictness. script-src 'self' 'unsafe-inline' no ofrece prácticamente ninguna protección, porque unsafe-inline permite exactamente la inyección que el encabezado existe para detener. Usa nonces o hashes en su lugar. Una fuente comodín como script-src * es el mismo problema en una forma diferente.

Inicia en el modo report-only, recopila las violaciones del tráfico real, endurece y luego ejecuta. La Website Security Test gratuita evalúa la solidez de la CSP en lugar de limitarse a comprobar su mera presencia, que es lo que realmente importa.

5. El resto de las cabeceras de seguridad

X-Content-Type-Options: nosniff impide que los navegadores adivinen los tipos de contenido, lo cual es cómo un archivo subido por un usuario se convierte en un script ejecutable.

X-Frame-Options: DENY, o mejor aún, frame-ancestors 'none' dentro de CSP, previene el clickjacking al impedir que tus páginas sean enmaradas.

Referrer-Policy: strict-origin-when-cross-origin impide la fuga de las URL completas, incluidos los identificadores de la ruta o la cadena de consulta, a terceros a través del encabezado Referer.

Permissions-Policy desactiva funciones del navegador que el sitio no utiliza, como cámara, micrófono y geolocalización, reduciendo lo que el script inyectado puede hacer.

Atributos de cookies

Cada cookie de sesión necesita tres atributos. Secure previene la transmisión por HTTP plano. HttpOnly mantiene la cookie fuera del alcance de JavaScript, lo que convierte muchos hallazgos de XSS de toma de cuenta en una molestia. SameSite=Lax o Strict bloquea el patrón de CSRF.

Es un cambio de una sola línea en casi todos los frameworks y aún falta en una gran parte de los sitios de producción.

7. Divulgación de la versión del software

Server: Apache/2.4.29 (Ubuntu) y X-Powered-By: PHP/7.2.24 le indican al atacante exactamente qué exploits publicados probar, antes de que haya enviado una sola solicitud relevante. Las etiquetas meta de generador, las rutas de recursos con versión y las páginas de error predeterminadas revelan la misma información.

Suprimir los encabezados no es una solución en sí misma, ya que la ocultación no soluciona nada, pero te elimina de las listas de objetivos de los escaneos masivos automatizados, lo que supone una reducción significativa del ruido.

8. Vulnerabilidades conocidas en el servidor y el CMS

La exposición de la versión solo importa porque el software obsoleto es muy común. Un servidor web, un CMS y sus plugins tienen cada uno su propio ciclo de lanzamientos, y los plugins suelen ser el eslabón más débil porque se instalan una vez y nunca se revisan de nuevo.

La Website Security Test gratuita identifica componentes de software obsoletos y vulnerables, además de realizar las comprobaciones de cabeceras y CSP, por lo que no requiere una herramienta separada.

9. DNSSEC y servicios expuestos

DNSSEC signs DNS responses so they cannot be forged in transit. Without it, an attacker who can manipulate DNS can send your users to their server with a valid certificate they obtained themselves.

Además de DNS, comprueba qué expone el servidor que no necesita: TRACE y otros métodos HTTP innecesarios, listados de directorios, directorios .git, archivos de copia de seguridad, paneles de administración accesibles desde Internet y endpoints de estado o métricas dejados abiertos.

Comprobaciones relacionadas que vale la pena realizar

Un servidor web no opera de forma aislada. Tres pruebas complementarias cierran las brechas restantes y toman un minuto cada una.

Email Security Test comprueba la parte de correo, donde los problemas de configuración de TLS y autenticación son mucho más frecuentes que en el servidor web, simplemente porque nadie los inspecciona.

Website Privacy Test muestra qué scripts, rastreadores y píxeles de terceros cargan tus páginas y dónde se envían tus formularios, lo cual es directamente relevante si el servidor gestiona pagos.

La prueba de Dark Web y exposición a amenazas busca en el exterior credenciales filtradas, dominios de squatting y sitios de phishing que usan tu marca, ninguno de los cuales aparece en un análisis del servidor.

Cómo ejecutar la prueba

La vía más rápida es la Website Security Test gratuita para encabezados, CSP, DNSSEC, versiones de software y cumplimiento de GDPR y PCI DSS, además de la SSL Security Test gratuita para la capa de cifrado. Ambas se ejecutan desde el navegador, no requieren cuenta y devuelven una calificación con un informe descargable.

Para comprobaciones repetidas, ambas pruebas se ejecutan desde la línea de comandos mediante iwtools, disponible como script de Python e imagen de Docker:

./iwtools.py websec --api-key ABCDE-12345-FGHIJ-67890 --recheck -p
https://example.com
./iwtools.py ssl --api-key ABCDE-12345-FGHIJ-67890 --recheck -p example.com:443

El código de salida 0 significa que todas las comprobaciones configuradas han pasado; el 3, que al menos una ha fallado. Eso basta para que un despliegue falle si desaparece un encabezado o reaparece una cifra débil.

Más allá de una prueba puntual

La deriva de la configuración. Los certificados caducan, una actualización de un plugin elimina un encabezado, un nuevo subdominio se lanza sin aplicar esto. La prueba te indica tu situación en un día concreto.

ImmuniWeb® Discovery descubre de forma continua los activos expuestos a Internet, incluidos aquellos que nadie ha registrado en seguridad, y supervisa su configuración, certificados y postura de cumplimiento con el tiempo. ImmuniWeb® Neuron cubre la capa de aplicación sobre el servidor con un SLA de cero falsos positivos.