Security

Cabeceras HTTP

Visualiza cabeceras de respuesta y audita políticas de seguridad.

Sobre esta herramienta

HTTP Headers recupera su URL con una petición HTTPS real, captura cada cabecera en la respuesta (y cada respuesta intermedia a lo largo de cualquier cadena de redirecciones) y pasa el resultado por una auditoría de seguridad que cubre las cabeceras modernas de hardening: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Cada cabecera se comprueba por presencia, sanidad del valor y huecos de buenas prácticas.

Más allá de la auditoría, listamos cada cabecera literalmente para que pueda confirmar la política de caché (Cache-Control, ETag, Vary), el rastro de CDN (CF-Ray, X-Cache, X-Served-By), compresión (Content-Encoding: br/gzip) y cualquier cabecera personalizada que emita su stack. El método HTTP (GET o HEAD), la versión HTTP negociada (HTTP/1.1, HTTP/2, HTTP/3) y la versión TLS se reportan en la barra de petición.

Cuándo utilizar esta herramienta

  • Hardening de seguridad. Antes de salir a producción, confirme que HSTS, CSP y el resto están establecidos con valores seguros — mínimo el nivel de Mozilla Observatory.
  • Depuración de caché. Vea exactamente qué Cache-Control y Vary emite su CMS o framework — causa común de «la versión vieja se queda pegada».
  • Auditorías de cadenas de redirección. Detecte cadenas accidentales 302-luego-301, bucles HTTP-a-HTTPS-a-host-distinto y canonicalización ausente.
  • Comportamiento del CDN. Confirme que Cloudflare/Fastly/CloudFront cachea realmente lo que cree leyendo las cabeceras Age, X-Cache y específicas del CDN.

Qué cubre nuestra auditoría de seguridad

Para cada una de las seis cabeceras de hardening reportamos: presente o ausente, el valor real y un veredicto breve («bueno», «necesita ajuste», «vulnerable»). HSTS sin includeSubDomains, CSP con unsafe-inline o Referrer-Policy dejada en su valor por defecto quedan señalados. Nunca le decimos cuál es la política «perfecta» porque cada sitio es distinto — pero le decimos qué mandos siguen en su valor de fábrica.

Preguntas frecuentes

¿Qué es HSTS y por qué importa?

Strict-Transport-Security le dice al navegador «usa siempre HTTPS para este dominio, aunque el usuario escriba http:// o haga clic en un enlace http://». Una vez establecido con un max-age razonable (típicamente 31536000 = 1 año), evita ataques de SSL-stripping en visitas posteriores. Añadir includeSubDomains extiende la protección a cada subdominio — buen valor por defecto para la mayoría de sitios pero asegúrese antes de que todos soportan HTTPS.

Falta mi CSP — ¿cómo de peligroso es?

Sin CSP, cualquier agujero XSS en su sitio se ejecuta con plenos poderes: puede exfiltrar cookies, cargar scripts controlados por el atacante o reescribir el DOM. Un CSP inicial de default-src 'self' bloquea los payloads XSS más comunes (scripts en línea, cargas de scripts externos) con coste casi nulo. Políticas más estrictas que prohíben scripts en línea por completo requieren refactorización pero ofrecen protección mucho más fuerte.

¿Siguen redirecciones?

Sí — hasta cinco saltos. Cada paso se muestra con su método, estado, location y cabeceras para que pueda detectar saltos con protocolos mixtos (HTTP→HTTPS), falta de canonicalización (apex vs www) o bucles accidentales. La mayoría de sitios de producción deberían redirigir como mucho una vez (HTTP → HTTPS) y luego servir contenido; más de dos saltos suele ser señal de reglas de reescritura solapadas.

¿Por qué la herramienta muestra HTTP/2 aunque configuré HTTP/3?

HTTP/3 (QUIC sobre UDP) requiere que el cliente opte mediante la cabecera Alt-Svc en la primera conexión. Nuestro comprobador usa HTTP/2 sobre TCP por defecto, que es lo que aún hace la mayoría de clientes HTTP hoy; si su servidor anuncia HTTP/3 en Alt-Svc, verá esa cabecera en el resultado, pero la respuesta en sí sigue siendo por HTTP/2. La presencia de Alt-Svc es lo que hay que buscar.