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.

Diagnosticar las cabeceras de seguridad de un sitio en producción

Introduzca una URL y el servidor acude a ese sitio, recupera sus cabeceras de respuesta y dictamina cómo están configuradas HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Separa lo que falta de lo que está presente pero es débil, y explica en cada caso cuál sería el problema.

**Lo que conviene tener presente es que una cabecera esté presente y que sea eficaz son dos cosas distintas.** HSTS puede muy bien estar puesta y, sin embargo, un `max-age` corto deja una ventana demasiado breve durante la cual el navegador exige HTTPS, con lo que la protección real resulta escasa. Por eso esta herramienta distingue el aprobado de la advertencia. **El otro punto es que las cabeceras que vuelven no fueron necesariamente añadidas por el servidor de origen.** Una CDN o un proxy inverso pueden insertarlas por el camino, en cuyo caso cambia también el lugar donde corregir la configuración. Lo que el diagnóstico muestra es el estado visible desde fuera; no puede decirle qué capa lo puso ahí.

Cómo se usa

  1. Introduzca la URL que desea examinar Indique una URL públicamente alcanzable que empiece por `https://`.
  2. Ejecute la comprobación **Los destinos inalcanzables desde fuera, como las direcciones IP privadas, se rechazan por prudencia.**
  3. Lea los dictámenes Vienen en tres grados, aprobado, advertencia y suspenso, donde la advertencia significa presente pero débil.
  4. Sírvase de las notas para corregir Cada entrada lleva una explicación de qué falla, lo que le permite fijar sus prioridades.

Consejos para aprovecharla mejor

  • 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 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.

Cuándo resulta útil

Hacer la comprobación final antes de publicar

Justo antes de la puesta en marcha puede confirmar desde fuera que las cabeceras previstas se devuelven de verdad.

Tomar ejemplo de otros sitios

**Ver hasta dónde han llegado sitios comparables le da una vara de medir para su propio nivel.**

Comparar antes y después de un cambio

Repita la comprobación una vez añadida una cabecera para confirmar que ha surtido efecto.

Revisar un sitio que ha heredado

**Se presta al inventario que sigue a un traspaso**, dándole una lista de lo que falta.

Términos de las cabeceras de seguridad

HSTS
Una cabecera que obliga a acceder por HTTPS en lugar de HTTP. **A menos que `max-age` alcance un año o más, la protección no dura lo suficiente.**
X-Content-Type-Options
Poner `nosniff` impide que el navegador adivine un tipo MIME a partir del contenido, lo que evita que un archivo se ejecute como algo que no es.
X-Frame-Options
Una cabecera que rehúsa dejar que su sitio se incruste en un marco. **En las políticas más recientes, `frame-ancestors` de CSP asume el mismo papel.**
Content-Security-Policy
El mecanismo que restringe de dónde pueden proceder los recursos cargables. Es la pieza central de la defensa frente al XSS.
Referrer-Policy
Una cabecera que decide cuánto de la URL de procedencia se entrega cuando un visitante pasa a otro sitio.
Permissions-Policy
Una cabecera que controla qué orígenes pueden usar funciones como la cámara, el micrófono y la ubicación.

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.
Tool-kun

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.