abusing-hop-by-hop-headers

Send a request with a security-relevant header like X-Forwarded-For, then repeat it while listing that header in the Connection header (e.g., Connection: close, X-Forwarded-For). If the response status or body changes, the proxy stripped the header, indicating a misconfiguration.

The Connection header lets a client designate arbitrary headers as hop-by-hop, so compliant proxies remove them before forwarding. Attackers exploit this to strip X-Forwarded-For, Authorization, or Cookie headers, bypassing IP allowlists or poisoning shared caches.

RFC 2616 section 13.5.1 defines Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization, and Proxy-Authenticate as hop-by-hop. Any additional header named in the Connection header must also be treated as hop-by-hop by compliant proxies.

Yes, when a backend trusts X-Forwarded-For for IP allowlisting. Stripping the attacker's spoofed XFF makes the backend see only the trusted proxy IP, potentially granting access to restricted endpoints like admin panels or bypassing rate limits and geofencing.

Send a request marking a session header like Cookie as hop-by-hop, then issue a clean follow-up request from a different session. If the second request receives the personalized or attacker-influenced response, confirmed by Age or X-Cache headers, the cache was poisoned.

Burp Suite Repeater is used to craft Connection header variations and diff responses against a baseline. curl handles quick manual probes, Param Miner discovers hidden headers, and simple Python scripts with the requests library automate testing across candidate headers.