Funciones / Seguridad de la respuesta
Cualquier cosa puede imprimir las cabeceras que devuelve un sitio. La pregunta útil es cuáles faltan, cuáles están puestas en algo que no hace nada y cuál de ellas es un agujero y no una tarea de refuerzo pendiente, y si algo de eso ha cambiado desde el último despliegue.
Pasa cualquier escáner de cabeceras y obtendrás un muro de rojo. Faltan nueve
cosas, cada una presentada con la misma urgencia, y la respuesta razonable a
partir de la segunda visita es dejar de mirar. Mientras tanto, el hallazgo que
de verdad importa —una cookie de sesión servida sin el flag Secure— está en
mitad de la lista con el mismo color que una Permissions-Policy ausente.
La evaluación existe para separar esas dos cosas. Aquí hay una sola clase de hallazgo tratada como problema real. Todo lo demás es refuerzo: conviene hacerlo, no conviene despertar a nadie por ello, y se informa en ámbar para que el día que algo se ponga rojo te lo creas.
Una cookie sin Secure. Una cookie de sesión sin Secure viaja en texto claro
la primera vez que alguien escribe la dirección sin https. Es el único hallazgo
aquí tratado como problema; el resto son refuerzos, y esa diferencia es justo el
punto.
Las cookies también se revisan buscando HttpOnly y SameSite, pero eso se
informa como aviso y nombrando cada cookie, porque el juicio depende de cuál
sea. Todos los frameworks incluyen una cookie CSRF que la página debe poder
leer; una cookie de sesión legible por scripts es otra cosa muy distinta.
Presente no es lo mismo que efectivo. Un max-age de menos de unos seis meses lo
olvida el navegador antes de que la mayoría renueve nada, y las listas de preload
lo rechazan, así que uno corto se informa en lugar de darse por bueno. Un sitio
con max-age=300 tiene una cabecera HSTS y, a efectos prácticos, no tiene HSTS.
Si el HTTP simple sigue respondiendo se revisa junto a eso. Una redirección a HTTPS está bien. Que el puerto 80 rechace directamente la conexión es mejor, y la diferencia se informa en lugar de aplanarse.
| Se revisa | Se informa como |
|---|---|
Content-Security-Policy |
Si existe siquiera, la defensa principal contra scripts inyectados |
| Protección contra marcos | La cumple X-Frame-Options o un frame-ancestors en la CSP; cualquiera sirve y solo una de ellas es la forma antigua |
X-Content-Type-Options |
Si se le dice al navegador que no adivine que una subida es un script |
Referrer-Policy |
Si las URL completas se filtran a cada sitio que enlazas |
Permissions-Policy |
Si el acceso a cámara, micrófono y ubicación está limitado |
Server, X-Powered-By |
Server y X-Powered-By con números de versión son reconocimiento gratuito para cualquiera que busque un fallo conocido justo en esa versión |
Una cabecera que desaparece es un evento. Una política que estaba la semana pasada y hoy no está queda escrita en el historial del sitio, porque eso es un despliegue que nadie pretendía hacer.
Esa es la diferencia real entre revisar cabeceras y monitorizarlas. Un análisis te dice el estado de un sitio en el momento en que lo lanzaste, y eso sirve una vez. Un sitio revisado a diario te dice cuándo cambió el estado, que es lo que de verdad necesitas cuando una actualización del framework deja caer un middleware sin avisar, o una configuración nueva del CDN elimina una cabecera al pasar.
Solo se registran las diferencias. Una comprobación que encuentra exactamente lo mismo que ayer no escribe nada, así que el historial es una lista corta de lo que se movió y no un año de filas idénticas.
No, y no debería venderse a un cliente como tal. Esto lee lo que el servidor devuelve en una petición normal a la página de inicio y lo evalúa. No busca vulnerabilidades, no prueba ninguna entrada y no se autentica.
Normalmente no. La mayoría son defensa en profundidad, y una aplicación bien construida sin ninguna de ellas es más segura que una mal construida con todas. Precisamente por eso se evalúan en vez de contarse: una puntuación sobre nueve invita a perseguir el número, y el número no es el punto.
La evaluación se toma de la respuesta de la página de inicio. Las cabeceras casi siempre se ponen de forma global —en el framework, el servidor web o el CDN—, así que la página de inicio es una lectura fiable de todo el sitio.
El hallazgo nombra la cabecera y qué permite su ausencia. No genera
configuración, porque la Content-Security-Policy correcta para un sitio depende
por completo de lo que ese sitio carga, y una política copiada de una herramienta
de monitorización o es tan laxa que no hace nada o tan estricta que rompe el
pago.
A diario, en todos los planes y para todos los sitios. El intervalo de comprobación de los planes de pago compra comprobaciones de disponibilidad más frecuentes; las pasadas diarias son iguales para todo el mundo.