Verificador de cabeceras de seguridad

Introduce la URL de un sitio para comprobar si cabeceras de seguridad clave como HSTS, CSP y X-Frame-Options están configuradas correctamente. Muestra qué cabeceras faltan o son débiles, junto con consejos para corregirlas.

Consejos

  • Esta herramienta obtiene la URL objetivo desde el servidor, por lo que puede comprobar las cabeceras de cualquier sitio sin toparse con las restricciones CORS del navegador.
  • Un max-age de HSTS más largo suele ser más seguro, pero si planeas cambiar la configuración de tu certificado, prueba primero con un valor más corto antes de aplicarlo en producción.
  • Combina esta herramienta con el Validador de CSP hermano (dev.server.csp_validator) para revisar en detalle la sintaxis real de tu Content-Security-Policy.
  • Esta herramienta reutiliza el mismo mecanismo de "introducir una URL y obtenerla desde el servidor" que el verificador de robots.txt, por lo que puede comprobar cualquier página pública sin autenticación.
  • Revisa tu propio sitio periódicamente para asegurarte de que un cambio en la configuración de una CDN o un proxy inverso no haya eliminado silenciosamente una cabecera de seguridad.

Preguntas frecuentes

La funcionalidad es similar, pero el verificador de Toolbase permite revisar los resultados y las explicaciones de corrección en japonés. La comprobación detallada de la sintaxis de CSP la gestiona la herramienta hermana Validador de CSP.

Sí, pero como HSTS solo tiene sentido para conexiones HTTPS, el elemento HSTS siempre se diagnosticará como fallido en un sitio que solo use HTTP. Deberías priorizar primero la migración completa del sitio a HTTPS.

Actualmente se recomienda la directiva frame-ancestors de Content-Security-Policy, pero como algunos navegadores antiguos no la admiten, la práctica habitual es especificar ambas como una doble capa de protección.

No. La solicitud a la URL que introduces se realiza en el momento, y la información de las cabeceras obtenida nunca se almacena en el servidor.

No necesariamente. Permissions-Policy en particular es una capa de defensa adicional opcional, y su prioridad puede ser menor según la naturaleza del sitio. Recomendamos mejorar primero elementos de alto impacto como HSTS, CSP y X-Frame-Options.
ツールくん

A propósito — securityheaders.com y la historia de la defensa contra el clickjacking

El diagnóstico de la configuración de seguridad a través de las cabeceras de respuesta HTTP ha estado dominado durante mucho tiempo por securityheaders.com, creado por Scott Helme. Dado que muchos servicios extranjeros solo explican los resultados y las correcciones en inglés, Toolbase creó su propio verificador para poder revisar resultados y explicaciones juntos en japonés como alternativa en este campo.

HSTS (HTTP Strict Transport Security) fue estandarizado por el IETF como RFC 6797 en 2012. El origen se remonta a una demostración de 2009 del "SSL Stripping", un ataque que aprovecha el breve momento en que un usuario escribe una URL sin https:// y el navegador se conecta primero por HTTP sin cifrar, permitiendo a un atacante reescribir el tráfico. HSTS permite que un navegador recuerde que "este dominio debe accederse siempre por HTTPS", evitando ataques de degradación tras la primera visita.

X-Frame-Options fue originalmente una cabecera de extensión propietaria introducida por Microsoft para Internet Explorer 8 en 2009, adoptada más tarde por otros navegadores hasta convertirse en un estándar de facto. La preocupación en aquel momento era el "clickjacking", donde un iframe invisible se superpone a un botón de apariencia auténtica para que el usuario haga clic sin darse cuenta. Hoy en día la industria avanza hacia la directiva frame-ancestors, más flexible, de Content-Security-Policy, pero especificar ambas sigue siendo recomendable como respaldo para navegadores antiguos que no la admiten.

→ Leer curiosidades relacionadas

→ Ver todas las curiosidades

Más herramientas en esta categoría