Comprobador de cabeceras HTTP

Ejecute el Comprobador de cabeceras HTTP tras desplegar un nuevo origen, cambiar modos orange-cloud del CDN o activar HSTS. Cache-Control y cabeceras específicas del CDN explican HTML obsoleto pese a un deploy reciente — compare ETag y max-age antes de purgar a ciegas. Si el banner Server difiere del esperado, confirme A/AAAA con el Comprobador DNS: puede estar llegando a una IP antigua del balanceador.

Las revisiones de seguridad usan HSTS, CSP, X-Frame-Options, Referrer-Policy y Permissions-Policy para medir el endurecimiento base. Sin HSTS en sitios solo HTTPS quedan ventanas de downgrade en la primera visita. Una CSP mal configurada rompe scripts en producción — el comprobador captura la política en vivo para diff con staging. El Comprobador de certificados SSL valida el certificado; las cabeceras validan lo que la app envía tras terminar TLS.

Depurar redirecciones beneficia de ver la cadena completa: enlaces cortos de marketing, reglas apex→www y upgrades http→https añaden saltos. Los hilos de soporte suelen necesitar el Location exacto del 301 — cópielo del comprobador en lugar de adivinar desde la barra del navegador que oculta pasos intermedios.

Equipos de API y SPA inspeccionan cabeceras CORS (Access-Control-Allow-Origin) cuando la consola muestra fetches bloqueados. Las cabeceras prueban lo que el edge devuelve a GET no autenticados — distinto del preflight POST que aún debe probarse aparte.

Proyectos de cumplimiento y banners de cookies catalogan atributos Set-Cookie: Secure, HttpOnly, SameSite. El comprobador documenta emisión en la URL analizada — útil antes de auditorías de privacidad. DN01 no escanea sitios enteros en cada ruta; empiece por la URL bajo investigación.

Los balanceadores a veces eliminan Server y añaden Via — documente ambos al endurecer la huella. Los pentesters usan variación de cabeceras para mapear CDN vs origen; su ticket de hardening debe listar diferencias intencionadas por hostname.

Apps móviles que llaman APIs pueden no mostrar DevTools — pegue URLs fallidas en el comprobador para capturar cabeceras 401/403 (WWW-Authenticate, Retry-After) sin reproducir en dispositivo.

Equipos de plataforma comparan cabeceras antes y después de activar compresión Brotli en el CDN — Content-Encoding y Vary deben alinearse con la política de caché que documenta su runbook de performance.

Durante auditorías SOC2 o ISO, exporte la salida del Comprobador de cabeceras HTTP junto con capturas del Comprobador DNS y Comprobador de certificados SSL para demostrar controles de borde sin afirmar cobertura global inexistente.

Cabeceras distintas en la misma URL desde VPN de oficina vs red móvil suelen indicar CDN geo-ruteado o registros A partidos — compare respuestas del Comprobador DNS y vuelva a fetch desde nuestra ruta. Mostramos una instantánea, no cincuenta edge nodes globales.

301 vs 302 vs 307 importan para SEO y preservación de método. El comprobador expone códigos por salto — no asuma que todas las redirecciones son equivalentes. Meta refresh en HTML queda fuera del alcance HTTP; vea el código fuente si falta Location pero el navegador se mueve.

Cache-Control obsoleto con max-age largo en CDN mientras el origen envía no-cache significa que la configuración del edge anula al origen — corrija la regla CDN, purgue y recompuebe. Cache-Control vacío en estáticos puede causar revalidación excesiva — intencional en HTML, costoso en assets inmutables.

Cabeceras de seguridad en www pero ausentes en apex (o viceversa) suelen indicar vhost incompleto. Compruebe ambos hostnames por separado. HSTS en una sola etiqueta deja hermanas vulnerables — alinee virtual hosts TLS y reejecute el Comprobador de certificados SSL para cobertura SAN.

Content-Encoding brotli o gzip afecta el cuerpo, no la semántica de cabeceras — no confunda falta de Content-Length en respuestas chunked con errores; centre cache y seguridad en auditorías de política.

Las cabeceras HTTP existen sobre TCP/TLS. Un certificado válido del Comprobador de certificados SSL no implica caché o CSP correctos. A la inversa, cabeceras perfectas en la IP equivocada significan que DNS aún apunta elsewhere para algunos resolvers — triangule con Comprobador DNS y DIG en A/AAAA.

Los proxies CDN terminan TLS y pueden eliminar o inyectar cabeceras. Server y Via revelan cuántos proxies participaron. Diagnóstico solo-origen requiere grey-cloud o fetch directo fuera del CDN — DN01 obtiene la URL pública que introduce, típicamente por la ruta que DNS define hoy.

Listas preload HSTS y certificate transparency quedan fuera del alcance. El comprobador muestra Strict-Transport-Security en respuestas en vivo — suficiente para muchas auditorías, no sustituto del registro preload ni monitor CT.

Automatice comprobaciones recurrentes vía API documentada tras registrar token. La UI del navegador sigue siendo ideal para investigaciones ad hoc con copia y etiquetas localizadas — no vendemos SIEM ni panel WAF completo.

HTTP/3 y QUIC cambian el establecimiento de conexión pero muchas cabeceras de seguridad siguen en la capa semántica HTTP — el comprobador documenta cabeceras en la ruta negociada hoy, no cada variante experimental de edge.

Respuestas 304 Not Modified dependen del If-None-Match del cliente — el comprobador en URL desnuda puede mostrar 200 mientras navegadores con ETag en caché ven 304; documente condiciones al comparar capturas de soporte.

DN01 no ejecuta JavaScript — SPAs que fijan cabeceras de seguridad solo tras render cliente pueden engañar si solo inspecciona URLs de hosting estático.

X-Content-Type-Options: nosniff y Cross-Origin-Opener-Policy complementan CSP en defensa en profundidad — el comprobador lista lo que el servidor declara en una sola solicitud GET reproducible en tickets.

Cuando un WAF devuelve páginas de desafío bot, las cabeceras pueden mostrar Set-Cookie de sesión de mitigación distintas de la aplicación — documente el hostname exacto bajo ataque antes de comparar con staging.

curl -I es el estándar del operador pero bloqueado en muchos portátiles corporativos e intimidante para compañeros no CLI. DN01 formatea cabeceras para copiar con cadenas de redirect visibles en un panel — misma clase de información, UX más amable, ocho idiomas.

Las pestañas Network de DevTools brillan en depuración interactiva con POST y WebSockets. El comprobador apunta a instantáneas GET/HEAD de metadatos de respuesta para tickets — no export HAR completo ni análisis waterfall.

Escáneres de seguridad dedicados rastrean sitios, puntúan cabeceras y rastrean CVE. DN01 ofrece fetch honesto de URL única sin badge de grado de pago — combine con su escáner para profundidad, use DN01 para «¿qué devuelve esta URL ahora?»

No seguimos redirects JavaScript arbitrarios, autenticamos apps ni almacenamos bases históricas por cliente. Rate limits protegen el servicio. Mapas de propagación globales quedan fuera — Comprobador DNS y DIG responden direccionamiento; nosotros metadatos HTTP de la URL enviada.

Equipos WAF empresariales mantienen allowlists para bots de inspección — los fetch DN01 parecen tráfico de monitorización normal pero coordine con su política de seguridad antes de automatizar alto volumen en producción.

Tag managers de terceros inyectan scripts que alteran rendimiento percibido — el comprobador documenta declaraciones del servidor; Lighthouse y RUM miden experiencia cliente. Use ambos cuando marketing pregunte por «cabeceras bien pero HTML obsoleto» — workers edge pueden reescribir cuerpos tras el origen.

Gateways proxy con auth devuelven 302 a login con Set-Cookie — capture esas cabeceras al depurar SSO; DN01 no mantiene sesiones autenticadas pero documenta redirects pre-auth que confunden clientes API que esperan JSON.

Herramientas APM correlacionan latencia con tamaño de respuesta — el comprobador no mide TTFB ni waterfall, pero prueba la política de caché declarada que APM no siempre expone en alertas de usuario.

Extensiones de navegador que modifican cabeceras localmente no reflejan lo que ven clientes externos — DN01 fetch desde infraestructura neutral evita falsos positivos de pruebas solo en laptop del desarrollador.

Runbooks de desastre deberían incluir re-ejecución del Comprobador de cabeceras HTTP tras fail-over DNS — confirme HSTS y redirects antes de declarar servicio restaurado al negocio.