Verificador de Headers HTTP
Analiza las cabeceras HTTP de respuesta para verificar seguridad, caché e info del servidor.
Headers de Seguridad que Verificamos
- • Strict-Transport-Security: Fuerza HTTPS
- • Content-Security-Policy: Previene ataques XSS
- • X-Frame-Options: Previene clickjacking
- • X-Content-Type-Options: Previene MIME sniffing
- • X-XSS-Protection: Filtro XSS
¿Por qué verificar Headers?
- • Identificar vulnerabilidades de seguridad
- • Verificar configuración del servidor
- • Verificar políticas de caché
- • Depurar respuestas de API
- • Analizar configuración de rendimiento
El header de seguridad que tu servidor ignora — y lo que eso expone en producción
Los headers HTTP de seguridad son directivas que el servidor envía para indicar al navegador cómo comportarse. Headers ausentes como Content-Security-Policy, X-Frame-Options y Strict-Transport-Security dejan tu sitio vulnerable a XSS, clickjacking y ataques de degradación de protocolo.
Obtuviste un 40% en el score de seguridad. Eso no significa que tu sitio fue comprometido — significa que tu respuesta HTTP omite headers que los navegadores modernos usan para aplicar políticas de seguridad. CSP bloquea la ejecución de scripts no autorizados. HSTS fuerza HTTPS en visitas futuras. X-Frame-Options impide que tus páginas sean incrustadas en iframes para clickjacking. Cada header que agregas cierra una superficie de ataque específica.
Headers HTTP para depurar caché, CORS y problemas de API
Cuando los usuarios ven contenido desactualizado tras un deploy, o un cliente de API rechaza una solicitud cross-origin, la causa casi siempre está en los headers HTTP. Cache-Control, Vary y Access-Control-Allow-Origin controlan exactamente esos comportamientos.
Un header Cache-Control: max-age=86400 significa que el navegador servirá contenido del caché por 24 horas — incluso después de un deploy con correcciones. Los errores de CORS por falta de Access-Control-Allow-Origin parecen fallas de red en el cliente, pero son problemas de configuración del servidor. Verificar los headers directamente revela lo que el servidor envía realmente, no lo que crees que configuraste.
Qué indica realmente un score de seguridad HTTP bajo — y qué corregir primero
El score de seguridad HTTP es el porcentaje de headers críticos que están presentes y correctamente configurados. Un score por debajo del 60% significa que múltiples headers están ausentes, dejando a los usuarios expuestos a XSS, clickjacking y ataques de degradación.
Empieza por los headers de mayor impacto: HSTS fuerza HTTPS en visitas repetidas y previene ataques SSL-strip. Content-Security-Policy restringe qué scripts y recursos pueden ejecutarse en la página. X-Frame-Options o la directiva frame-ancestors del CSP impide que tu página de login sea incrustada en un iframe malicioso. Agrega estos tres y tu score sube significativamente.
Verificar headers Set-Cookie para detectar sesiones configuradas de forma insegura
Un header Set-Cookie sin las flags Secure e HttpOnly significa que los tokens de sesión son accesibles por JavaScript y transmisibles por HTTP — ambos son riesgos de seguridad en producción.
Si tu aplicación usa cookies para autenticación, los headers de respuesta revelan exactamente cómo están configuradas. Flag Secure ausente significa que las cookies se envían por HTTP. Flag HttpOnly ausente significa que JavaScript puede leer la cookie — haciendo que los ataques XSS sean inmediatamente peligrosos. SameSite=Lax o Strict previene cross-site request forgery. No son configuraciones abstractas — son valores que el servidor define por respuesta.