Verificador de Cabeceras HTTP Online Gratis

Q: ¿Por qué HEAD devuelve a veces cabeceras distintas que GET?

Según RFC 9110 §9.3.2 (Fielding/Nottingham/Reschke, junio 2022), el método HEAD devuelve las mismas cabeceras de respuesta que GET haría para el mismo target, pero sin cuerpo de mensaje. En la práctica algunos servidores y CDNs difieren entre los dos: las capas de caché pueden servir una respuesta HEAD obsoleta desde caché mientras regeneran GET; algunos servidores de aplicación omiten Set-Cookie y Content-Length en HEAD porque no hay cuerpo que dimensionar; el middleware de rate-limit puede tratar HEAD distinto a GET. Cuando HEAD devuelve 405 Method Not Allowed (común en scripts CGI legacy y algunos endpoints CMS), la herramienta recurre a GET con Range: bytes=0-0, lo que obtiene el primer byte y lee las mismas cabeceras que un GET real produciría — preciso sin descargar el cuerpo entero.

Q: ¿Qué cabeceras de seguridad son críticas, y a qué deberían configurarse?

El proyecto OWASP Secure Headers recomienda una base de cinco: (1) Strict-Transport-Security (RFC 6797 Hodges/Jackson/Barth, 19 de noviembre 2012) — configura max-age=31536000 (1 año) + includeSubDomains + preload, luego envía a hstspreload.org; (2) Content-Security-Policy (W3C CSP Nivel 3 Working Draft, última revisión abril 2026) — como mínimo default-src 'self' + un script-src basado en nonce 'strict-dynamic', evita 'unsafe-inline' y 'unsafe-eval'; (3) X-Content-Type-Options: nosniff — previene ataques de MIME-sniffing; (4) Referrer-Policy: strict-origin-when-cross-origin — filtra menos detalles de URL a terceros; (5) Permissions-Policy (W3C Working Draft, que reemplaza Feature-Policy) — deshabilita APIs sensibles que no uses (camera=(), microphone=(), geolocation=()). X-Frame-Options (RFC 7034) queda obsoleta por CSP frame-ancestors y solo se mantiene por compatibilidad con navegadores antiguos.

Q: ¿Debería seguir configurando X-Frame-Options si tengo CSP frame-ancestors?

X-Frame-Options (RFC 7034 Ross y Gondrom, octubre 2013) y la directiva CSP frame-ancestors (introducida en CSP Nivel 2, mantenida en Nivel 3) controlan si tu página puede ser embebida en un frame. Cuando ambas están presentes, los navegadores modernos (Chrome, Firefox, Safari, Edge) honran CSP frame-ancestors e ignoran X-Frame-Options según la especificación W3C. El HTML Living Standard nota explícitamente X-Frame-Options como obsoleta. Consejo práctico: usa frame-ancestors como política primaria (más flexibilidad — permite múltiples dominios específicos, admite 'self' + esquema + puerto), mantén X-Frame-Options: DENY o SAMEORIGIN como fallback legacy solo si necesitas compatibilidad con navegadores anteriores a ~2015 (raro para contextos sensibles de seguridad).

Q: ¿Cómo funcionan los nonces CSP, y por qué se prefieren a 'unsafe-inline'?

CSP Nivel 3 admite un flujo basado en nonce que permite scripts inline controlados sin recurrir a 'unsafe-inline'. El servidor genera un valor aleatorio fresco por petición (≥128 bits, codificado base64) y lo emite tanto en la cabecera CSP (script-src 'nonce-r4nd0m...') como en cada etiqueta inline legítima. El navegador solo ejecuta scripts inline cuyo atributo nonce coincide con el valor de la cabecera; los scripts inyectados desde XSS no tendrán el nonce y son bloqueados. Añadir 'strict-dynamic' a la directiva script-src (CSP Nivel 3) extiende la confianza transitivamente a scripts cargados por scripts con nonce, eliminando la necesidad de listar fuentes de host. Esta combinación ('nonce-X' + 'strict-dynamic') es la mejor práctica CSP moderna, alineada con las recomendaciones del proyecto OWASP Secure Headers.

Q: ¿Cómo puedo comprobar que HTTP/2 o HTTP/3 se usa realmente?

Los navegadores modernos y curl --http2 / curl --http3 negocian la versión de protocolo más alta que ambos extremos admiten vía ALPN (Application-Layer Protocol Negotiation) durante el handshake TLS. La respuesta en sí no incluye una cabecera de versión de protocolo, pero varias señales revelan lo que se usó: (1) curl con -v muestra el resultado ALPN y el protocolo usado en el setup de conexión; (2) la cabecera de respuesta alt-svc le dice a los clientes sobre la disponibilidad de HTTP/3 (h3) para peticiones futuras, p.ej. 'alt-svc: h3=":443"; ma=2592000'; (3) las DevTools del navegador (panel Network) muestran el protocolo por petición — h2 para HTTP/2, h3 para HTTP/3; (4) algunos CDNs añaden cabeceras diagnósticas como cf-ray (Cloudflare). RFC 9114 (HTTP/3, junio 2022) requiere transporte QUIC; RFC 9113 (HTTP/2, junio 2022) reemplazó al RFC 7540 con el mismo formato de wire. Esta herramienta detecta el protocolo vía la implementación fetch() subyacente cuando está disponible.

Verificador Cabeceras HTTP — Seguridad, Base OWASP y Detección de Protocolo

Las cabeceras HTTP de respuesta llevan metadatos sobre la respuesta del servidor: tipo de contenido, reglas de caché, políticas de seguridad y negociación de protocolo. La especificación principal actual de semántica HTTP es el RFC 9110 (Fielding, Nottingham y Reschke, junio 2022), un Internet Standard (STD 97) que deja obsoletos los RFC 7231-7235 y actualiza partes del RFC 7230 (la mensajería HTTP/1.1 está dividida en el RFC 9112). El cacheo lo gobierna el RFC 9111. Las cabeceras de seguridad forman una capa de defensa en profundidad: Strict-Transport-Security (HSTS) según el RFC 6797 (Hodges, Jackson y Barth, 19 de noviembre de 2012) fuerza HTTPS y previene ataques de downgrade; Content-Security-Policy Nivel 3 (W3C Working Draft, última revisión abril 2026) restringe qué scripts, estilos, frames y conexiones puede cargar la página; Permissions-Policy (W3C Working Draft) controla el acceso a APIs sensibles del navegador como cámara, micrófono y geolocalización, reemplazando a la Feature-Policy desfasada tras la división de 2020 en Permissions-Policy y Document-Policy; X-Frame-Options (RFC 7034 Ross y Gondrom, octubre 2013) queda obsoleta a favor de CSP frame-ancestors. El proyecto OWASP Secure Headers recomienda una base que incluye HSTS con includeSubDomains + preload, CSP sin unsafe-inline, X-Content-Type-Options: nosniff y Referrer-Policy: strict-origin-when-cross-origin. Esta herramienta hace fetch a la URL, muestra cada cabecera de respuesta y marca las cabeceras de seguridad ausentes contra esa base.

Cómo inspeccionar cabeceras HTTP

Introduce una URL. La herramienta emite una petición HEAD (o recurre a GET con Range: bytes=0-0 si HEAD es rechazado con 405).
Todas las cabeceras de respuesta se muestran con valores analizados; las cabeceras de seguridad se puntúan contra la base OWASP Secure Headers.
Las cabeceras de seguridad ausentes (CSP, HSTS, X-Content-Type-Options, Permissions-Policy) se marcan con el valor de directiva recomendado.
Las redirecciones se trazan — cada salto muestra código de estado, target Location y sus propias cabeceras de respuesta según RFC 9110.

Casos de uso comunes

Auditar cabeceras de seguridad (HSTS, CSP, Permissions-Policy) antes de un despliegue a producción — caza regresiones cuando la config nginx/CDN deriva.
Verificar que Cloudflare u otro CDN realmente sirve tu contenido (cf-ray, server, x-cache visibles).
Depurar problemas de caché inspeccionando Cache-Control, Age, ETag y Vary en una respuesta de producción.
Confirmar que un servidor usa HTTP/2 o HTTP/3 — la cabecera alt-svc señala disponibilidad de upgrade; la negociación ALPN se completa durante el handshake TLS.

Preguntas frecuentes

¿Por qué HEAD devuelve a veces cabeceras distintas que GET?

Según RFC 9110 §9.3.2, HEAD devuelve las mismas cabeceras que GET haría, pero sin cuerpo. En la práctica algunos servidores omiten Set-Cookie/Content-Length en HEAD; algunos CDNs cachean HEAD distinto. Cuando HEAD devuelve 405, la herramienta recurre a GET con Range: bytes=0-0 — mismas cabeceras, sin descargar el cuerpo entero.

¿Qué cabeceras de seguridad son críticas, y a qué deberían configurarse?

Base OWASP: HSTS (RFC 6797, max-age=31536000 + includeSubDomains + preload), CSP Nivel 3 (default-src 'self' + 'strict-dynamic' basado en nonce), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy deshabilitando APIs no usadas. X-Frame-Options queda obsoleta por CSP frame-ancestors.

¿Debería seguir configurando X-Frame-Options si tengo CSP frame-ancestors?

Los navegadores modernos priorizan CSP frame-ancestors e ignoran X-Frame-Options cuando ambas están presentes (según especificación W3C). frame-ancestors es más flexible (múltiples dominios, esquemas, puertos). Mantén X-Frame-Options: DENY solo como fallback legacy para navegadores anteriores a ~2015.

¿Cómo funcionan los nonces CSP, y por qué se prefieren a 'unsafe-inline'?

CSP Nivel 3: el servidor genera nonce aleatorio fresco por petición (≥128 bits, base64), lo emite en la cabecera CSP (script-src 'nonce-X') + en cada etiqueta <script nonce='X'>. El navegador solo ejecuta scripts con nonce coincidente. Añadir 'strict-dynamic' extiende la confianza a scripts cargados por scripts con nonce. Mejor práctica CSP moderna.

¿Cómo puedo comprobar que HTTP/2 o HTTP/3 se usa realmente?

Negociado vía ALPN durante el handshake TLS; protocolo no en cabeceras de respuesta directamente. Señales: curl -v muestra el resultado ALPN; la cabecera alt-svc anuncia disponibilidad de HTTP/3 (h3) para futuras peticiones; el panel Network de DevTools muestra el protocolo por petición. RFC 9114 = HTTP/3 sobre QUIC; RFC 9113 = HTTP/2 sobre TCP.

Anatomía de las cabeceras HTTP de respuesta — y por qué las cabeceras de seguridad importan

Las respuestas del servidor llevan docenas de cabeceras que los navegadores, CDNs e intermediarios inspeccionan para renderizar el contenido correctamente y aplicar los límites de seguridad. La semántica principal vive en el RFC 9110 (junio 2022), que reestructuró los RFC 7231-7235 en un único documento que define métodos, códigos de estado y semántica de campo independiente de cualquier versión específica de HTTP (1.1, 2 o 3). Las cabeceras se dividen en cuatro grupos funcionales: representación (Content-Type, Content-Encoding, Content-Length), validación/condicional (ETag, Last-Modified, If-None-Match según RFC 9110 §13), caché (Cache-Control, Age, Vary según RFC 9111) y política de seguridad. El stack de seguridad importa porque el comportamiento por defecto del navegador es permisivo: sin política explícita, los scripts se ejecutan desde cualquier origen, los frames se embeben sin restricción y las APIs sensibles están disponibles para cualquier documento. Strict-Transport-Security (RFC 6797, noviembre 2012) fuerza HTTPS durante una duración configurable; la lista de preload en hstspreload.org da protección al apex para visitantes nuevos antes de que ocurra cualquier petición HTTP. Content-Security-Policy Nivel 3 (W3C Working Draft, revisión de abril 2026) reemplaza las vulnerabilidades de 'unsafe-inline' con flujos basados en nonce/hash y la fuente strict-dynamic. La directiva frame-ancestors dentro de CSP supersede a X-Frame-Options (RFC 7034 Ross y Gondrom, octubre 2013, ahora obsoleta) — los navegadores modernos priorizan frame-ancestors cuando ambas están presentes, según la especificación W3C. Permissions-Policy (W3C Working Draft, que reemplaza Feature-Policy tras la división de 2020 en Permissions-Policy + Document-Policy) restringe el acceso a cámara, micrófono, geolocalización y otras APIs sensibles a nivel de documento. El proyecto OWASP Secure Headers sintetiza esto en una base de auditoría: HSTS preload, CSP basado en nonce, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy deshabilitando las APIs no usadas. Esta herramienta lee cada cabecera de respuesta, analiza los valores y marca los elementos ausentes contra esa base.

Todas las cabeceras de respuesta mostradas con valores analizados
Auditoría de seguridad contra base OWASP (HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
Comprobación de elegibilidad para HSTS preload (max-age ≥ 1 año, includeSubDomains, directiva preload)
Parser de directivas CSP Nivel 3 con avisos de obsolescencia (frame-ancestors > X-Frame-Options)
Parseo de Cache-Control / Age / Vary según RFC 9111; ETag / Last-Modified según RFC 9110 §8.8
Detección de protocolo HTTP/1.1, HTTP/2 (RFC 9113), HTTP/3 (RFC 9114) vía señales alt-svc + ALPN

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (7)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — Internet Standard STD 97; obsoletes RFC 2818 + 7231-7233 + 7235 + 7538/7615/7694 + portions of 7230; RFC 7234 → RFC 9111; RFC 7230 messaging → RFC 9112).
Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Caching. RFC 9111, IETF (June 2022 — obsoletes RFC 7234).
Hodges, J., Jackson, C., & Barth, A. (2012). HTTP Strict Transport Security (HSTS). RFC 6797, IETF (19 November 2012 — Strict-Transport-Security header field).
West, M. (Ed.) (2026). Content Security Policy Level 3. W3C Working Draft (latest revision April 2026; supersedes CSP Level 2; frame-ancestors directive — introduced in CSP Level 2 (W3C Recommendation December 2016) and carried forward in Level 3 — supersedes X-Frame-Options RFC 7034).
W3C Web Application Security WG (2025). Permissions Policy. W3C Working Draft (replaces deprecated Feature-Policy after 2020 split into Permissions-Policy + Document-Policy).
Ross, D., & Gondrom, T. (2013). HTTP Header Field X-Frame-Options. RFC 7034, IETF (October 2013, Informational; obsoleted by CSP frame-ancestors directive introduced in CSP Level 2).
OWASP (2025). OWASP Secure Headers Project. owasp.org/www-project-secure-headers — recommended baseline: HSTS preload + CSP + X-Content-Type-Options nosniff + Referrer-Policy strict-origin-when-cross-origin + Permissions-Policy.

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Códigos de estado HTTP en monitoreo — Cuáles disparan alertas y cuáles noNo todo no-200 es una caída. Guía práctica de qué códigos HTTP deberían despertarte y cuáles son solo ruido.

Por Marco B. · Última verificación junio 2026 — corre en tu navegador