Lee los Security Headers de HTTP que envía realmente un sitio web y descubre cuáles faltan, cuáles son débiles o cuáles se anulan entre sí de forma imperceptible. Gratis, sin necesidad de crear una cuenta.
Comprobación de cabeceras de seguridad
Los Security Headers son instrucciones que un servidor web envía con cada respuesta para activar las protecciones con las que ya cuenta el navegador: qué fuentes pueden ejecutar scripts, si el sitio web se puede cargar a través de HTTP sin cifrar y si otro sitio web puede incrustarlo en un marco. La herramienta «Security Header Check» de ReportedIP lee esos cabeceras, evalúa cada uno de ellos en función de lo que realmente impide y señala el cambio concreto que hay que realizar para subsanar cada fallo.
Cómo funciona esta herramienta y cuáles son sus limitaciones
La dirección se obtiene mediante una solicitud GET normal, tras un máximo de tres redireccionamientos, y se leen los cabeceras de la respuesta. Se utiliza GET en lugar de HEAD porque un buen número de servidores, proxies inversos y cortafuegos responden a las solicitudes HEAD desde una ruta de código diferente con un conjunto de cabeceras más reducido, lo que haría que se indicara que faltan cabeceras que un navegador real sí recibe. La comprobación se realiza desde este servidor, por lo que un sitio web que varíe sus cabeceras según el país, el agente de usuario o el estado de Login puede responder de forma diferente en tu caso.
La puntuación es ponderada, no un recuento. «Content-Security-Policy» y «Strict-Transport-Security» son los que más peso tienen, ya que determinan si se ejecuta un script inyectado y si se puede forzar que una solicitud vuelva a HTTP sin cifrar. «Referrer-Policy» y «Permissions-Policy» limitan las fugas de información y tienen menos peso. COOP, COEP y CORP no tienen ningún peso: existen para aislar las páginas que necesitan temporizadores de alta resolución, y un sitio web que no los necesite no es menos seguro por prescindir de ellos.
No se indica que falte el cabecera X-Frame-Options cuando la política Content-Security-Policy establece el parámetro «frame-ancestors». «frame-ancestors» es el sucesor especificado, todos los navegadores actuales lo respetan y permite nombrar orígenes permitidos de forma individual, algo que X-Frame-Options nunca ha podido hacer. Una «Content-Security-Policy» enviada únicamente en modo «Report-Only» se trata como lo que es: un instrumento de medición que registra las infracciones y no bloquea nada.
Solo se lee una página. Las cabeceras suelen configurarse a nivel del servidor o del proxy y, por lo tanto, se aplican en todas partes, pero una aplicación puede añadirlas o eliminarlas por ruta, por lo que comprobar la página que realmente importa (la de Login o la de finalización de la compra) tiene más valor que comprobar la página de inicio. La herramienta solo lee los cabeceras y nunca inspecciona el contenido de la página, por lo que no puede determinar si una política es realmente lo suficientemente amplia como para que el sitio web funcione.
Por qué una lista de encabezados no es una puntuación
La mayoría de los verificadores de encabezados te ofrecen una lista de comprobación y una puntuación. Esto equipara la ausencia de «Permissions-Policy» con la de «Content-Security-Policy», cuando no es así. Uno de ellos limita lo que puede hacer la API del navegador; el otro marca la diferencia entre que se ejecute o no un script entre sitios web.
Esta comprobación pondera cada encabezado en función de lo que evita. «Content-Security-Policy» es lo que más cuenta, seguido de HSTS, la protección contra el framing y la detección del tipo de contenido. Los encabezados de aislamiento entre orígenes se incluyen en el informe, pero se puntúan con cero, ya que un sitio web que nunca los haya necesitado no debería perder puntos por ello.
En qué se equivoca una lista de comprobación
«frame-ancestors» sustituye a «X-Frame-Options».
Un sitio web con una «Content-Security-Policy» adecuada no necesita el encabezado antiguo, y exigir ambos es un consejo de hace diez años. Una política de solo informe no cuenta, porque los navegadores no la aplican.
«max-age=0» es peor que no tener HSTS.
Le indica activamente al navegador que olvide que el sitio web fue alguna vez exclusivamente HTTPS. Una lista de comprobación ve que el encabezado está presente y marca la casilla.
El HSTS sobre HTTP sin cifrar no significa nada.
Los navegadores lo ignoran en ese contexto, por lo que la comprobación lo excluye del cálculo en lugar de restar puntos por ello.
Lo que lee
La página se recupera con una solicitud GET normal, no HEAD, porque algunos servidores responden de forma diferente a ambas y lo que importa son los encabezados que ve el navegador. Solo se inspeccionan los encabezados de respuesta; el contenido de la página no se almacena.