Client-IP & Header Trust Boundary

These checks send a distinctive, non-routable (RFC 5737 TEST-NET-3, or an .invalid hostname) marker value in a client-supplied header, and check whether it’s reflected back in the response body or headers. Reflection is a black-box heuristic for “this header is trusted” — proxyaudit has no visibility into what actually reaches the origin behind the proxy.

Astuce

A response with no reflection at all doesn’t prove the header is safely handled — it may just mean nothing in the response happens to echo request headers. Treat these checks as a signal to investigate, not a definitive pass/fail.

Check ID	Title	CVSS 4.0	CWE	OWASP
headertrust.x_forwarded_for	X-Forwarded-For Value Reflected	5.3	CWE-348	API8:2023
headertrust.x_real_ip	X-Real-IP Value Reflected	5.3	CWE-348	API8:2023
headertrust.true_client_ip	True-Client-IP Value Reflected	5.3	CWE-348	API8:2023
headertrust.x_forwarded_host	X-Forwarded-Host Value Trusted	5.3	CWE-350	API8:2023
headertrust.host_header_injection	Host Header Value Trusted	5.3	CWE-350	API8:2023
headertrust.vhost_confusion	Virtual-Host Confusion via Crafted Host Header	6.5	CWE-441	API8:2023
headertrust.forwarded_consistency	Forwarded Header Inconsistent With Legacy Headers	4.8	CWE-348	API8:2023
headertrust.acl_bypass	IP-Based Access Control Bypassed via Spoofed Client-IP Header	8.7	CWE-290	API5:2023

headertrust.x_forwarded_for / headertrust.x_real_ip / headertrust.true_client_ip

Sends a spoofed value in the respective client-IP header and checks for reflection, tested independently since a proxy may honor one and not the others.

Remediate: at the edge, overwrite (not append/trust) these headers with the actual peer address, or strip them from inbound requests before forwarding.

headertrust.x_forwarded_host

Sends a spoofed X-Forwarded-Host and checks for reflection — e.g. in a redirect Location header or a canonical link, which would indicate a host-header-poisoning-style trust issue (password reset links, cache poisoning).

Remediate: don’t use client-supplied X-Forwarded-Host to build absolute URLs unless it’s set (and can’t be overridden) by the proxy itself.

headertrust.host_header_injection

Sends a spoofed Host header — the request line itself, not X-Forwarded-Host — and checks for reflection, e.g. in a generated password-reset link, redirect Location header, or canonical link. This catches origins that build absolute URLs straight from Host without going through a proxy-supplied X-Forwarded-Host at all.

Remediate: build absolute URLs from a configured canonical hostname, never from the inbound Host header.

headertrust.vhost_confusion

Unlike the reflection-based checks above, this one sends a fixed list of common internal/admin hostnames (e.g. internal-admin.local) as the Host header and compares the response body against a baseline request made with the target’s own host — a direct test of whether the client-supplied Host header can route the request to a different (potentially internal) backend, rather than just a signal that the header is trusted somewhere.

Remediate: route on the SNI/listener the connection was actually received on (or an explicit virtual-host allowlist), not the client-supplied Host header.

headertrust.forwarded_consistency

Sends distinct spoofed values in the RFC 7239 Forwarded header and the legacy X-Forwarded-For header in the same request, and checks whether both, one, or neither is reflected — inconsistent handling between the two formats means a request can pick whichever header favors it.

Remediate: normalize to a single authoritative source (typically Forwarded per RFC 7239, or X-Forwarded-For if that’s what the stack already relies on) and ignore the other.

headertrust.acl_bypass

Unlike the reflection-based checks above, this one probes a fixed list of common internal/admin paths and compares the response with and without a spoofed loopback X-Forwarded-For/X-Real-IP header — a direct test of whether an IP-based access control (or a downstream rate limit keyed on the same header) can be bypassed, rather than just a signal that the header is trusted somewhere.

Remediate: enforce IP-based access controls and rate limits on the actual TCP peer address, not a client-supplied header; if a trusted proxy legitimately needs to forward the original client IP, overwrite (don’t append/trust) the header at the edge.