Cybersecurity glossary
What is X-Forwarded-For?
Learn what the X-Forwarded-For HTTP header does, how reverse proxies append client IPs, why spoofing is dangerous without trusted proxy lists, and how applications should read it safely.
Definition
X-Forwarded-For is a de-facto standard HTTP request header that lists the client IP addresses observed as a request passes through proxies and load balancers, with each trusted hop typically appending the address it saw on the inbound connection so backends can recover the original client IP behind TLS-terminating infrastructure.
Why X-Forwarded-For matters
Behind every CDN, API gateway, and Kubernetes ingress, backends see proxy IPs—not end-user IPs. X-Forwarded-For is how operators thread original client addresses through that chain for logging, fraud detection, geo routing, and rate limiting.
Used correctly with trusted proxy configuration, it restores visibility. Trusted blindly, it becomes one of the easiest headers to spoof.
How X-Forwarded-For flows through proxies
Each trusted hop appends the remote address it observed. The leftmost entry is often the original client; the rightmost is the most recent proxy. Parsing rules depend on how many trusted layers sit in front of your application.
Client connects to the edge
The user reaches a CDN, load balancer, or reverse proxy over the public internet.
Edge observes the client IP
The proxy records the TCP source address of the inbound connection.
Proxy appends to X-Forwarded-For
The hop adds the observed IP to the header chain before forwarding upstream.
Origin receives the chain
The application reads X-Forwarded-For only if the immediate peer is on the trusted proxy list.
App applies policy
Rate limits, audit logs, and geo rules use the derived client IP—not the proxy's socket address.
Spoofing vs trusted configuration
| Scenario | Risk if mishandled | Correct approach |
|---|---|---|
| Client sends X-Forwarded-For directly | Forged IP bypasses allowlists and rate limits | Ignore forwarding headers unless the peer IP is a trusted proxy |
| Multiple proxy hops | Parsing the wrong list position attributes traffic to the wrong host | Configure hop count or use framework support for trusted proxy depth |
| Logging for compliance | Audit trails record attacker-chosen IPs | Log both socket IP and parsed client IP with trust metadata |
| IPv6 and NAT | Ambiguous or truncated address lists | Normalize addresses; document whether IPv4-mapped forms are expected |
| Mixing Forwarded and X-Forwarded-For | Applications disagree on which header is authoritative | Standardize on one header at the edge and document parsing rules |
Operational patterns
Trusted proxy allowlist
Maintain CIDR ranges for your CDN, ingress controllers, and corporate egress proxies. Reject forwarding headers from everyone else.
Rightmost trusted IP
After validating the peer, take the last address your edge added—not the leftmost client-supplied value.
Strip at the edge
Some platforms remove inbound X-Forwarded-For from untrusted clients before appending a fresh value.
Framework integration
Express trust proxy, Django USE_X_FORWARDED_HOST, and similar settings encode hop trust explicitly.
Dual logging
Store connection IP and derived client IP to debug misconfiguration without losing forensics.
Prefer RFC 7239 Forwarded
Greenfield designs can emit structured Forwarded headers while supporting X-Forwarded-For for compatibility.
Security checklist
- Define a trusted proxy list with exact CIDR ranges—never trust the entire internet.
- Ignore X-Forwarded-For on requests that did not arrive through a listed proxy hop.
- Do not use the leftmost X-Forwarded-For value for security decisions unless you fully control every upstream hop.
- Configure framework trust-proxy settings to match your real ingress depth.
- Revisit the allowlist when migrating CDNs, adding new regions, or changing ingress controllers.
- Never expose raw X-Forwarded-For to end users in UI or APIs without validating trust.
- Pair IP-derived controls with stronger signals—authentication, device binding, or behavioral scoring.
- Test spoofing explicitly: send forged X-Forwarded-For from outside the proxy path and confirm rejection.
Limits and pitfalls
X-Forwarded-For is informative, not authentic. It carries no cryptographic proof of origin. Carrier-grade NAT, corporate proxies, and privacy VPNs also mean the "client IP" may represent a household or data center, not an individual.
Some teams log the entire comma-separated chain for debugging but apply policy to a single derived address. Document which position your code reads—off-by-one errors in multi-hop chains are common during infrastructure changes.
The practical takeaway
X-Forwarded-For restores client IP visibility behind reverse proxies, but only when your application trusts headers from known proxy ranges and parses the chain correctly.
Maintain an accurate trusted proxy list, strip or ignore spoofed values from direct clients, and never treat X-Forwarded-For as stronger than the trust boundary that appended it.
Related security terms
Reverse Proxy
Infrastructure that terminates TLS and appends forwarding headers toward origins.
Load Balancer
Often the hop that sets or extends X-Forwarded-For for backend pools.
X-Forwarded-Proto
Companion header that records the original request scheme seen by the edge.
Rate Limiting
Controls that frequently key on client IP derived from forwarding headers.
Frequently asked questions
What is X-Forwarded-For in simple terms?
When users connect through a proxy or load balancer, the backend only sees the proxy's IP. X-Forwarded-For carries a comma-separated list of client and proxy addresses so the application can learn who originally connected.
Can clients spoof X-Forwarded-For?
Yes. Any client can send X-Forwarded-For on a direct connection. Applications must ignore client-supplied values unless the immediate peer is a trusted proxy that strips or overwrites untrusted headers before appending the real observed address.
Which IP should my application trust?
Read the rightmost address that your trusted proxy added—the one closest to the end of the list that you know your edge appended. Frameworks often expose this as the client IP when configured with a correct trusted proxy list.
What is a trusted proxy list?
It is an explicit allowlist of load balancer, CDN, or reverse-proxy IP ranges whose forwarding headers your application will accept. Requests from any other source should not influence IP-based access control, logging, or rate limits.
How is X-Forwarded-For different from the Forwarded header?
Forwarded is the standardized RFC 7239 header with structured parameters. X-Forwarded-For is older and more widely deployed. Many stacks set both; applications should pick one parsing strategy and configure proxies consistently.
What goes wrong if I trust X-Forwarded-For blindly?
Attackers bypass IP allowlists, evade rate limits, poison audit logs, and trigger geo rules incorrectly. Security decisions based on a spoofable header create a false sense of protection.
References
Explore authoritative guidance and frameworks related to x-forwarded-for.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.