Comprobar cabeceras de seguridad
Escribe una dirección. Salen las seis cabeceras que importan, cada una con lo que su valor consigue de verdad — y las que están ahí sin hacer nada se dicen.
Por qué «estar» no es una nota
Todos los demás comprobadores puntúan por presencia: está la cabecera, verde. Pero una cabecera puede estar y no hacer absolutamente nada — max-age=0 es la forma documentada de apagar el HSTS, una política en modo Report-Only avisa y no bloquea, y frame-ancestors hace que el navegador ignore por completo tu X-Frame-Options. Las tres se leen como hechas. Y eso es peor que si faltaran, porque una cabecera que se ve es una cabecera que se deja de mirar.
Lo que esto no te dice
Si tu sitio es seguro. Estas cabeceras limitan lo que un ataque puede hacer una vez que algo ha salido mal; no hacen nada contra el fallo que lo dejó entrar. Un seis perfecto aquí convive tan tranquilo con un gestor de contenidos sin actualizar.
Si estás aquí, esto suele ser lo siguiente
Una foto, o la película entera
Esto es cómo está el sitio ahora mismo. La vigilancia lo mira —el certificado, el DNS, la disponibilidad— y te avisa el día que algo cambia, que suele ser el día que alguien desplegó una configuración que no leyó.
Preguntas frecuentes
- Dice que mi cabecera no hace nada. Si la veo en la respuesta.
- Nosotros también la vemos, y ése es el asunto. Tres de éstas aparecen puestas e inertes continuamente: el HSTS con max-age=0 (que es la orden de olvidarlo), una Content-Security-Policy mandada sólo como Report-Only (avisa, no bloquea) y un X-Frame-Options en un sitio cuya política trae además frame-ancestors, que es a la que el navegador hace caso. El valor está en el informe; compáralo con lo que creías haber puesto.
- ¿Hacen falta las seis?
- Cinco son una línea de configuración cada una y no hay motivo para no ponerlas. La Content-Security-Policy es la que cuesta trabajo de verdad, porque una estricta rompe los guiones en línea hasta que los arreglas — y es también la única que limita el daño de un XSS en vez de confiar en evitarlo. Ésa se despliega primero en Report-Only, se leen los avisos, y luego se enciende.
- ¿Por qué es un problema unsafe-inline si lo demás está cerrado?
- Porque es justo lo que una CSP existe para impedir. Con unsafe-inline en script-src, una etiqueta script inyectada se ejecuta — y eso es el ataque entero. Todo lo demás que restrinja la política vale menos que ese hueco. La salida son los nonce o los hash, y strict-dynamic te deja conservar el unsafe-inline como red para navegadores viejos sin que cuente en tu contra.