⌘K
ENES
GitHub
conceptRedes~8 min de lecturaActualizado Apr 29, 2026#cybersecurity#networking#http#headers

Headers HTTP

Definición

Los headers HTTP son campos de metadata nombrados en las requests y responses que le dicen a clientes, servidores, proxies, cachés y navegadores cómo interpretar el mensaje. Cargan señales de ruteo, identidad, estado, contenido, caché y política del navegador.

Por qué importa

Los headers son la capa de dirección de la seguridad HTTP. El body puede cargar el dato de negocio, pero los headers deciden de quién parece venir la request, qué host/path/protocolo cree el backend que se usó, si una response puede cachearse, si un navegador puede exponer una response cross-origin y cómo debe interpretarse el contenido.

La lección recurrente: los headers no son metadata neutral. Son inputs de múltiples parsers y motores de política independientes.

Esta nota es dueña de la semántica de headers. Mensajes HTTP es dueña del framing crudo del mensaje; Confianza en la IP del cliente es dueña de la confianza en la IP forwarded; Cookies y sesiones es dueña del estado Set-Cookie / Cookie; Caché y seguridad es dueña del comportamiento de clave de caché.

Cómo funciona

Todo header tiene tres propiedades que importan para la seguridad:

  1. Dirección. Los headers de request van cliente/proxy → servidor. Los de response van servidor/proxy → cliente. Algunos son válidos en ambas direcciones pero significan cosas distintas.
  2. Alcance. Los headers end-to-end están pensados para el destinatario final; los headers hop-by-hop aplican solo a una conexión y no deberían forwardearse más allá de ese hop.
  3. Intérprete. Un navegador, CDN, WAF, reverse proxy, framework, caché o aplicación pueden leer cada uno el mismo header de forma distinta.

Request y response de ejemplo:

GET /account HTTP/1.1
Host: app.example.com
Cookie: __Host-session=9f2a...
Authorization: Bearer eyJ...
X-Forwarded-For: 203.0.113.42
Origin: https://app.example.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store
Set-Cookie: __Host-session=9f2a...; Path=/; Secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'

Los mismos bytes cargan al menos cinco significados de seguridad: identidad, estado, ruteo, comportamiento de caché y política del navegador.

El bug suele vivir donde un componente trata un header como autoritativo aunque otro componente pueda proveer, transformar, omitir, duplicar o ignorar el mismo header.

Técnicas / patrones

Atacantes y defensores inspeccionan:

  • headers de ruteo: Host, X-Forwarded-Host, Forwarded, X-Original-URL, X-Rewrite-URL
  • headers de identidad: Authorization, Cookie, X-Forwarded-For, X-Real-IP, True-Client-IP
  • headers de estado: Set-Cookie, Cookie, validadores de caché, Origin / Referer adyacentes a CSRF
  • interpretación de contenido: Content-Type, Content-Length, Transfer-Encoding, Content-Encoding, Accept
  • política del navegador: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy, headers de CORS
  • comportamiento de caché: Cache-Control, Vary, ETag, Age, Surrogate-Control, headers de estado de caché específicos del CDN
  • rarezas de normalización: headers duplicados, diferencias de casing, espacio en blanco, valores unidos por coma, variantes agregadas-por-proxy vs provistas-por-cliente

Variantes y bypasses

Las fallas de seguridad de headers HTTP caen en 6 clases semánticas. Esta taxonomía es más útil que memorizar nombres de header individuales.

1. Headers de identidad y autorización

Cookie y Authorization prueban la identidad de la aplicación solo si el servidor los valida correctamente. Los headers de identidad forwarded como X-Forwarded-For no prueban nada salvo que el camino de red sea confiable. Headers de auth duplicados o en conflicto pueden producir desacuerdo proxy/backend.

2. Headers de ruteo y origen

Host, Forwarded, X-Forwarded-Host, X-Forwarded-Proto y los headers de rewrite influyen en la generación de URLs, el ruteo de virtual-host, los links de reset de contraseña y el comportamiento de redirect interno. Si el backend confía en headers de ruteo provistos por el atacante, siguen la inyección de host-header y los bugs de proxy-bypass.

3. Headers de estado y cookies

Set-Cookie y Cookie son especiales porque los navegadores los guardan y reproducen automáticamente. Su seguridad depende de atributos, alcance, reglas de prefijo y transporte. Cookies y sesiones es dueña de la profundidad completa.

4. Headers de interpretación de contenido

Content-Type, Content-Encoding, Content-Length y Transfer-Encoding le dicen a los parsers cómo leer los bytes. El desacuerdo acá lleva a XSS vía confusión de MIME, request smuggling vía framing del body, huecos de validación de upload y parseo de API roto.

5. Headers de control de caché

Cache-Control, Vary, ETag y los headers específicos del CDN deciden si la response de un usuario puede volverse la response de otro. Cualquier header que el origin lea pero que la caché no incluya en la clave es un input candidato a cache-poisoning.

6. Headers de política del navegador

CSP, HSTS, CORS, X-Frame-Options, Permissions-Policy y Referrer-Policy modelan lo que los navegadores permiten. Estos headers reducen la explotabilidad cuando son correctos pero a menudo se malentienden como reemplazos de la validación o autorización del lado del servidor.

Impacto

Ordenado aproximadamente por severidad:

  • Bypass de autenticación o autorización. Authorization en conflicto, headers forwarded confiados o headers de ruteo pueden hacer que el backend crea que una request vino de un camino o identidad privilegiada.
  • Request smuggling y confusión de parser. Content-Length, Transfer-Encoding, headers duplicados y rarezas de espacio en blanco pueden hacer que dos componentes parseen requests distintas.
  • Cache poisoning / fugas de caché sensibles. Cache-Control faltante, Vary débil o headers sin clave pueden exponer contenido personalizado o controlado por el atacante.
  • Amplificación del impacto de XSS. CSP faltante, Content-Type equivocado o responses sniffables amplían los caminos de ejecución del lado del cliente.
  • CSRF y exposición de datos cross-origin. SameSite débil, CORS permisivo o mal manejo de Origin deja que el contexto del navegador haga demasiado.
  • Confusión de frontera de confianza. Los headers inyectados por el proxy se vuelven indistinguibles de los provistos por el cliente salvo que se sobrescriban y validen en la frontera.

Detección y defensa

Ordenado por efectividad:

  1. Definí qué componente es dueño de cada header relevante para la seguridad.
    El edge debería ser dueño de los headers de forwarding, protocolo e IP de cliente. La aplicación debería ser dueña de la validación de auth/sesión y la autorización de negocio. Los headers de política del navegador deberían emitirse deliberadamente por la app o el edge, no accidentalmente por los defaults del framework. La propiedad previene que dos componentes acepten silenciosamente señales en conflicto.
  2. Sobrescribí los headers entrantes no confiables en las fronteras de confianza.
    Los reverse proxies deben sobrescribir, no agregar ni preservar, X-Forwarded-*, Forwarded y los headers de identidad/ruteo relacionados. Los backends deberían confiar en esos headers solo desde rangos de origen de proxy conocidos. Esto elimina la falla común de "el atacante proveyó un header que la app creía que solo el proxy podía setear".
  3. Rechazá headers críticos malformados, ambiguos y duplicados.
    Fallá cerrado ante Host duplicado, Content-Length / Transfer-Encoding en conflicto, terminaciones de línea inválidas, nombres de header con espacio en blanco y headers de auth duplicados. La ambigüedad es donde vive el desacuerdo de parsers.
  4. Emití política de caché explícita para responses sensibles.
    Usá Cache-Control: no-store para páginas autenticadas y responses de API sensibles. Al cachear variantes públicas, hacé que Vary coincida con cada header de request que cambia la response. Las cachés no pueden proteger datos que no se les dijo que eran privados.
  5. Seteá los headers de política del navegador como defensa en profundidad.
    HSTS, CSP, frame-ancestors o X-Frame-Options, Referrer-Policy y Permissions-Policy reducen la explotabilidad en los navegadores. Van después de la corrección del lado del servidor porque restringen clientes en vez de arreglar autorización rota.
  6. Normalizá y logueá el valor interpretado, no solo el header crudo.
    Los logs deberían registrar tanto las señales crudas donde sea útil como el valor que la aplicación realmente usó: IP de cliente percibida, host seleccionado, esquema de auth, content type, estado de caché. Esto hace visible el desacuerdo proxy/backend durante el testing y los incidentes.

Qué no funciona como defensa primaria

  • Agregar headers de seguridad mientras se dejan los bugs del lado del servidor intactos. CSP no arregla los sinks de XSS, CORS no autoriza usuarios, HSTS no vuelve seguro el HTTP del origin y X-Frame-Options no protege los endpoints que cambian estado.
  • Confiar en un header porque "el navegador lo setea". Origin, Referer, User-Agent y la mayoría de los headers de request pueden estar ausentes, ser forjados por clientes no-navegador o transformados por proxies. Tratalos como señales con restricciones, no verdad de base.
  • Hacer blocklist de nombres de header malos. Los atacantes usan variantes: casing distinto, headers duplicados, nombres legacy, Forwarded vs X-Forwarded-*, espacio en blanco, listas unidas por coma y alias específicos del framework.
  • Asumir que el framework ve lo que vio el edge. CDNs, WAFs, proxies y load balancers normalizan los headers antes de que la aplicación los lea. Testeá la cadena completa.
  • Confiar en los headers de response para secretos. Los headers son visibles para los clientes y a menudo para logs/proxies. No pongas secretos bearer ni detalles internos sensibles en headers custom.

Labs prácticos

Corré esto contra sistemas que sean tuyos o que estés autorizado a testear. curl, openssl, nc y rg estándar cubren lo básico.

Inventariar los headers de seguridad de la response

curl -skI https://app.example.com/ | rg -i \
  '^(strict-transport-security|content-security-policy|x-frame-options|frame-options|referrer-policy|permissions-policy|cache-control|vary|content-type|set-cookie):'

Buscá HSTS faltante en sitios HTTPS, CSP faltante o débil, protección de frame ausente, páginas autenticadas cacheables y atributos de cookie.

Comparar headers de caché públicos y autenticados

# Página pública
curl -skI https://app.example.com/ | rg -i '^(cache-control|vary|etag|age|x-cache|cf-cache-status):'

# Página autenticada con un cookie jar
curl -sk -b /tmp/app.cookies -I https://app.example.com/account | \
  rg -i '^(cache-control|vary|etag|age|x-cache|cf-cache-status):'

Esperado: las responses autenticadas o personalizadas no deberían ser guardadas por cachés compartidas.

Sondear el manejo de host y forwarded-host

curl -skI https://app.example.com/reset \
  -H 'Host: evil.example' \
  -H 'X-Forwarded-Host: evil.example' \
  -H 'X-Forwarded-Proto: http'

Vigilá redirects, URLs absolutas, links de reset de contraseña en cuentas de prueba y links canónicos generados. Un backend que refleja host/proto controlado por el atacante tiene un bug de confianza de ruteo.

Sondear la confianza en headers de IP de cliente

curl -skI https://app.example.com/admin \
  -H 'X-Forwarded-For: 127.0.0.1' \
  -H 'X-Real-IP: 127.0.0.1' \
  -H 'Forwarded: for=127.0.0.1;proto=https;host=app.example.com'

Un cambio de status, contenido, bucket de rate-limit o log significa que el backend puede confiar en headers de forwarding provistos por el cliente. Ver Confianza en la IP del cliente para el flujo más profundo.

Sondear headers críticos duplicados

# Host duplicado a través de HTTP crudo.
printf 'GET / HTTP/1.1\r\nHost: app.example.com\r\nHost: evil.example\r\nConnection: close\r\n\r\n' \
  | openssl s_client -quiet -connect app.example.com:443 -servername app.example.com 2>/dev/null

# Authorization duplicado a través de curl.
curl -skI https://app.example.com/api/me \
  -H 'Authorization: Bearer valid-test-token' \
  -H 'Authorization: Bearer invalid-test-token'

Esperado: los duplicados críticos deberían ser rechazados o manejados de forma consistente por cada hop.

Inspeccionar los bytes exactos de header de request/response

curl -sk --trace-ascii /tmp/headers.trace https://app.example.com/login \
  -H 'X-Debug-Probe: header-lab' >/dev/null

rg -n '=> Send header|<= Recv header|X-Debug-Probe|Set-Cookie|Cache-Control' /tmp/headers.trace

Esto muestra lo que curl realmente envió y lo que el servidor realmente devolvió, sin la abstracción de la UI del navegador.

Ejemplos prácticos

  • Un backend construye URLs de reset de contraseña a partir de X-Forwarded-Host; un atacante inyecta su dominio y captura los tokens de reset.
  • Un CDN solo usa la URL como clave mientras el origin varía la salida según X-Forwarded-Host, creando web cache poisoning.
  • Un WAF rechaza Transfer-Encoding: chunked, pero el backend acepta Transfer-Encoding: chunked con espacio extra.
  • Una API acepta dos headers Authorization; el proxy valida uno mientras la app lee el otro.
  • Un sitio setea CSP en las páginas HTML pero deja los endpoints de JSON o file-preview con Content-Type equivocado, habilitando bugs de interpretación del navegador.
  • Una response incluye Access-Control-Allow-Origin: * con comportamiento credentialed en otro lado, revelando que la política de CORS no tiene dueño central.

Notas relacionadas

Notas atómicas futuras sugeridas

  • Inyección de host-header
  • Headers de seguridad en la response
  • Content-type sniffing
  • Resolución de headers duplicados
  • Spec del header Forwarded
  • Semántica de Cache-Control
  • Permissions-Policy

Referencias

  • Foundational: MDN HTTP headers — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
  • Foundational: RFC 9110 (HTTP Semantics) — https://datatracker.ietf.org/doc/html/rfc9110
  • Mitigation: OWASP HTTP Headers Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
  • Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security

Notas relacionadas

RedesCaché y seguridadEl caché es el reuso de responses generadas previamente por navegadores, CDNs, reverse proxies, intermediarios compartidos o capas de aplicación. El caché se vuelve un problema de seguridad cuando una response se almacena, se le hace clave, se varía o se invalida de forma distinta a como la aplicación espera. RedesConfianza en la IP del clienteLa confianza en la IP del cliente es la pregunta de qué IP trata una aplicación como "el cliente" cuando las requests pasan por cualquier intermediario — reverse proxy, load balancer, CDN, WAF o sidecar de service-mesh. El bug rara vez es "leímos el header equivocado". El bug es que la traducción de confianza entre la identidad de red y la identidad de header HTTP no está auditada: el proxy dice una verdad, el backend cree otra distinta y el atacante elige cuál. RedesCookies y sesionesLas cookies son estado cargado por headers HTTP que los navegadores guardan y adjuntan automáticamente a requests posteriores. Las sesiones son el modelo de continuidad del lado del servidor o respaldado por token que le permite a una aplicación reconocer "al mismo usuario" a través de requests HTTP que de otro modo no tienen estado. RedesMensajes HTTPUn mensaje HTTP es la unidad de datos intercambiada entre cliente y servidor — ya sea una request (enviada cliente → servidor) o una response (enviada servidor → cliente). En HTTP/1.x el mensaje es un flujo de texto con framing CRLF estricto; en HTTP/2 y HTTP/3 el mensaje es una secuencia de frames binarios que cargan campos lógicamente equivalentes. Esta nota se enfoca en el formato de mensaje de HTTP/1.1 porque ahí es donde viven las decisiones de parseo relevantes para la seguridad, y donde cada hop que habla HTTP/1.1 en una cadena moderna se ve forzado a tomarlas. RedesPanorama de HTTPHTTP (Hypertext Transfer Protocol) es el protocolo de aplicación request/response que transporta la abrumadora mayoría del tráfico web y de APIs. El formato de wire es basado en texto en HTTP/1.x y con framing binario en HTTP/2 y HTTP/3. El protocolo no impone semántica — la transporta. Toda vulnerabilidad web se presenta en última instancia como una transacción HTTP cuyas partes fueron parseadas, confiadas o ruteadas de una forma que el diseñador no pretendía. RedesReverse proxiesUn reverse proxy es un intermediario HTTP que acepta requests en nombre de uno o más servicios de backend, aplica un conjunto fijo de transformaciones y forwardea el resultado al backend que elige. La propiedad que lo define no es "balancea carga" — el balanceo de carga es una transformación. La propiedad que lo define es que el proxy y el backend parsean cada uno la request de forma independiente, lo que vuelve al proxy una frontera de confianza cada vez que sus interpretaciones difieren.