Visor de Headers HTTP
Visor de cabeceras HTTP con tarjeta de seguridad: obtenga una nota A+ a F para HSTS, CSP, X-Frame-Options, CORS, y vea sus propias cabeceras.
Visor de Headers HTTP - Verificar y Analizar Headers HTTP Online
Las cabeceras HTTP son los metadatos que viajan con cada petición y respuesta web — la parte que nunca se ve en la barra de direcciones pero que controla cómo funciona el caché, qué scripts pueden cargarse, si sus cookies sobreviven a recargas, si el sitio puede embeberse en un iframe, qué compresión se usa, y cómo el navegador interpreta el cuerpo de la respuesta. Esta herramienta expone ambos lados de esa conversación: en un panel ve las cabeceras de SU navegador (User-Agent, Accept, Accept-Encoding, Cookie, Sec-Fetch-*, Sec-CH-UA — los nuevos Client Hints que gradualmente reemplazan a User-Agent), y en el otro puede consultar cualquier URL HTTP/HTTPS e inspeccionar sus cabeceras de respuesta (código de estado con la frase razón estándar, Content-Type con charset, reglas Cache-Control, Set-Cookie con todos los flags de seguridad, política Strict-Transport-Security, directivas Content-Security-Policy, X-Frame-Options para protección anti-clickjacking, Access-Control-Allow-Origin para configuración CORS, huella del software servidor). Útil para depurar integraciones API, validar endurecimiento de seguridad (compruebe que su sitio envía HSTS y un CSP estricto), ingeniería inversa de comportamiento de caché, o aprender cómo se comporta realmente la capa de protocolo web. Los objetivos bloqueados por CORS son comunes — el mensaje le dirá cuándo ocurre, y en esos casos la pestaña Network del DevTools del navegador queda como respaldo.
¿Qué son los Headers HTTP?
Los headers HTTP son metadatos enviados entre un cliente (navegador) y servidor en solicitudes y respuestas HTTP. Contienen información importante sobre:
- Detalles de solicitud (tipo de navegador, formatos aceptados, autenticación)
- Detalles de respuesta (tipo de contenido, reglas de caché, cookies)
- Políticas de seguridad (CORS, CSP, X-Frame-Options)
- Codificación y compresión de contenido
- Gestión de conexión
Los headers son esenciales para la comunicación web adecuada y afectan cómo los navegadores manejan el contenido.
¿Cómo uso este Visor de Headers HTTP?
Usar la herramienta es sencillo:
1. Vea sus headers de solicitud actuales en la sección 'Sus Headers de Solicitud'
2. Para verificar headers de una URL, ingrésela en el campo URL
3. Haga clic en 'Verificar Headers' para obtener los headers de respuesta
4. Revise el código de estado, headers y valores
Nota: Debido a restricciones CORS (Intercambio de Recursos de Origen Cruzado), algunos sitios web pueden bloquear solicitudes de headers desde navegadores. Este es comportamiento de seguridad normal.
¿Qué son los Headers de Solicitud?
Los headers de solicitud son enviados por el navegador al servidor e incluyen:
- User-Agent: Información de navegador y SO
- Accept: Tipos de contenido que el navegador puede manejar
- Accept-Language: Idiomas preferidos
- Accept-Encoding: Métodos de compresión compatibles
- Cookie: Cookies almacenadas para el dominio
- Referer: URL de página anterior
- Authorization: Credenciales de autenticación
Estos headers ayudan a los servidores a entender las capacidades y preferencias del cliente.
¿Qué son los Headers de Respuesta?
Los headers de respuesta son enviados por el servidor e incluyen:
- Código de Estado: Resultado de la solicitud (200 OK, 404 Not Found, etc.)
- Content-Type: Tipo de contenido que se devuelve
- Content-Length: Tamaño del cuerpo de respuesta
- Set-Cookie: Cookies para almacenar
- Cache-Control: Instrucciones de caché
- Access-Control-*: Permisos CORS
- Server: Software del servidor web
Los headers de respuesta le dicen al navegador cómo manejar el contenido recibido.
¿Qué significa el error CORS?
CORS (Intercambio de Recursos de Origen Cruzado) es un mecanismo de seguridad que previene que los navegadores hagan solicitudes a dominios diferentes al que sirve la página. Cuando ve un error CORS:
- El servidor objetivo no permite solicitudes de origen cruzado
- Este es comportamiento de seguridad intencional
- No es un problema con esta herramienta o su navegador
- Muchos sitios web bloquean CORS por seguridad
Para evitar CORS:
- Use extensiones de navegador que deshabiliten CORS (solo para pruebas)
- Pruebe URLs que tengan CORS habilitado
- Use herramientas del lado del servidor para pruebas de producción
- Verifique los headers del sitio web real usando DevTools del navegador (F12 → pestaña Network)

¿Qué cabeceras de seguridad debe enviar todo sitio web moderno?
La línea base mínima en 2026 incluye siete cabeceras. (1) Strict-Transport-Security (HSTS): fuerza HTTPS durante el próximo año — 'max-age=31536000; includeSubDomains; preload'. (2) Content-Security-Policy: lista blanca de orígenes script/estilo/imagen permitidos — empiece con 'default-src 'self'' y ajuste desde ahí. (3) X-Content-Type-Options: 'nosniff' — previene ataques de MIME-sniffing donde el navegador intenta adivinar si un .txt es realmente JS. (4) X-Frame-Options: 'DENY' o 'SAMEORIGIN' — bloquea que su sitio sea enmarcado por atacantes (clickjacking). (5) Referrer-Policy: 'strict-origin-when-cross-origin' — limita cuánta info de referente se filtra a terceros. (6) Permissions-Policy: desactive funciones que no usa (cámara, micrófono, geolocalización, USB). (7) Cross-Origin-Opener-Policy: 'same-origin' — habilita protección Spectre y APIs crossOriginIsolated. Mozilla Observatory (observatory.mozilla.org) las califica; apunte a una A+.
¿Por qué un 200 OK solo muestra unas 6 cabeceras?
Este es el comportamiento más confuso de cualquier visor de cabeceras basado solo en el navegador, y no es un error. Cuando el fetch tiene éxito con CORS pero el servidor NO envía la cabecera Access-Control-Expose-Headers, el navegador solo deja que JavaScript lea el conjunto de la lista segura CORS: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified y Pragma. Todo lo demás — Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Set-Cookie, Server y el resto — se sigue enviando por la red y el navegador lo aplica, pero queda oculto al script por razones de privacidad/seguridad. Así que un sitio perfectamente sano puede devolver un 200 OK y exponer aquí solo ~6 cabeceras legibles. Cuando detectamos este caso mostramos una nota informativa. Para inspeccionar el conjunto completo (incluidas las cabeceras de seguridad que necesita la tarjeta), abra DevTools del navegador (F12 → Network), haga clic en la petición y lea el panel de Cabeceras de Respuesta — DevTools no está limitado por la regla Expose-Headers.
¿Qué significa mi nota de seguridad y cómo arreglo una cabecera fallida?
Tras un fetch exitoso, la Tarjeta de Seguridad de Cabeceras audita siete cabeceras base y asigna una nota general de A+ a F (cada cabecera cuenta igual; un 'aviso' vale medio aprobado). A+/A significa que cumple o casi cumple la línea base de endurecimiento de 2026; B es aceptable pero mejorable; C y D significan que faltan protecciones importantes; F significa que faltan la mayoría de las cabeceras de seguridad. Cada fila fallida o con aviso muestra una pista de corrección de una línea con la directiva exacta a añadir. Correcciones típicas: HSTS — envíe 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' (un max-age menor solo gana un aviso); CSP — empiece con "default-src 'self'" y ajuste; X-Content-Type-Options — 'nosniff'; framing — 'X-Frame-Options: DENY' o una directiva CSP 'frame-ancestors'; Referrer-Policy — 'strict-origin-when-cross-origin'; Permissions-Policy — desactive funciones no usadas; Cross-Origin-Opener-Policy — 'same-origin'. Nota: si CORS oculta las cabeceras de respuesta (vea la pregunta anterior), la tarjeta solo puede calificar lo que puede leer, así que verifique con DevTools para un resultado fiable. Esto refleja la calificación de Mozilla Observatory, en línea e instantánea.
¿Por qué obtengo IP/servidor diferente al verificar desde aquí vs mis logs?
Porque la petición desde su navegador pasa por varias capas antes de llegar al servidor origen. (1) El NAT saliente de su ISP traduce su IP local a una pública — su servidor ve la IP pública NATeada, no su dirección doméstica. (2) Los edges CDN (Cloudflare, Fastly, Akamai) terminan la conexión TLS en el punto geográfico más cercano — su servidor ve la IP del edge CDN, no la del visitante. La IP real del visitante, si se reenvía, vive en cabeceras X-Forwarded-For o CF-Connecting-IP que la CDN inserta. (3) Proxies inversos (nginx, HAProxy) frente a su app ocultan el cliente de forma similar. (4) La cabecera Server en la mayoría de sitios modernos está intencionalmente falseada o eliminada — seguridad por oscuridad. Para ver la cadena real, solicite un endpoint de debug en su propio servidor que haga eco de las cabeceras que recibe, luego compare con lo que esta herramienta muestra saliendo del navegador.
¿Mis datos están seguros?
Sí, sus datos son completamente seguros:
- Toda verificación de headers ocurre en su navegador
- Sus headers de solicitud se leen del navegador mismo
- Al verificar URLs, las solicitudes van directamente de su navegador a esa URL
- Ningún dato se envía a nuestros servidores
- Sin registro o rastreo de URLs que verifica
- Funciona offline para ver sus propios headers
La herramienta es completamente del lado del cliente, asegurando su privacidad.
Características Clave
- Ver sus headers de solicitud HTTP actuales
- Verificar headers de respuesta de cualquier URL
- Mostrar códigos de estado HTTP
- Mostrar todos los pares clave-valor de headers
- Analizar headers CORS
- Verificar headers de caché
- Ver cookies y headers de autenticación
- Soporte de modo oscuro
- Procesamiento 100% del lado del cliente - los datos nunca salen de su navegador
- Sin registro requerido
- Funciona con cualquier URL HTTP/HTTPS
- Visualización de headers limpia y fácil de leer
- Copiar headers al portapapeles
- Tarjeta de seguridad de cabeceras con nota
- Diseño responsive amigable con móviles
