Handle X-Forwarded-For so it can't be spoofed

The fix/etc/haproxy/haproxy.cfg

frontend web
    # Overwrite anything the client sent, then append the real source
    http-request del-header X-Forwarded-For
    option forwardfor

Delete first, then let forwardfor add the value HAProxy actually observed.

Why appending is the problem

option forwardfor inserts the client’s address into X-Forwarded-For. HAProxy’s documentation is precise about how: the header “is always appended at the end of the existing header list”, and it notes that “it is really possible that the client has already brought one.”

So if a client sends this:

GET / HTTP/1.1
X-Forwarded-For: 10.0.0.1

the backend receives:

X-Forwarded-For: 10.0.0.1
X-Forwarded-For: 203.0.113.45

The first value is attacker-controlled. The second is real. Nothing in the request marks which is which — the backend has to know the convention.

This turns into a vulnerability the moment something acts on that address:

• Allow-lists. A backend that admits requests from 10.0.0.1 because it is “internal” can be reached by anyone willing to type that header.
• Rate limiting. Per-IP limits keyed on a spoofable value are trivially evaded by varying it.
• Audit logs. The address in your incident timeline is whichever one the application happened to pick up.

Two fixes

Delete then append, as in the fix block above, is the one to prefer at an internet-facing edge. After del-header, exactly one X-Forwarded-For reaches the backend and it is the one HAProxy observed. Nothing downstream has to know the convention.

Read the last occurrence is the alternative when you cannot change the proxy — HAProxy’s docs state that “the server must be configured to always use the last occurrence of this header only.” This is correct but fragile: it relies on every consumer, including frameworks and middleware you did not write, agreeing to count from the right. Many default to the leftmost value precisely because that is the original client in a well-behaved chain.

If HAProxy is behind another proxy or a CDN, deleting the header discards a real address you need. There, keep the chain and configure the application with the number of trusted hops, or use the standardised Forwarded header via option forwarded.

Do not reach for if-none

option forwardfor if-none only adds the header when one is not already present — which means a client that supplies its own keeps it, unmodified. HAProxy’s documentation attaches an explicit warning: it “should only be used in perfectly trusted environment, as this might cause a security issue if headers reaching HAProxy are under the control of the end-user.”

On an internet-facing frontend, headers reaching HAProxy are by definition under the control of the end user. if-none is for chained proxies on a private network, and even then except is usually the better tool:

option forwardfor except 127.0.0.0/8

Verify it worked

Prove it from outside by sending a header a real client would never send:

curl -sS -H 'X-Forwarded-For: 10.0.0.1' https://your-site.example/whatever

Then look at what the backend received. If the application echoes it, compare; otherwise read the backend’s own access log — it should record your real address, and 10.0.0.1 should appear nowhere.

Check the configuration for the risky variants:

grep -nE 'forwardfor|forwarded|X-Forwarded-For' /etc/haproxy/haproxy.cfg

if-none on an internet-facing frontend is the finding.

You can also log what arrives, which is the fastest way to see spoofing in progress:

http-request capture req.hdr(X-Forwarded-For) len 50

A captured value on a frontend that faces the internet directly means somebody is sending one.

Before you apply this

Deleting X-Forwarded-For at the edge is safe only if HAProxy is the first thing the client reaches. If there is a CDN, a cloud load balancer, or another reverse proxy in front, del-header throws away the real client address and every downstream log and rate limiter starts seeing the upstream proxy instead.

Establish your position first:

grep -c 'X-Forwarded-For' /var/log/haproxy.log

Requests arriving with the header already set, consistently, from a small set of source addresses, means something is in front of you.

Changing this also changes what your application sees, so anything keyed on client IP — session pinning, geolocation, fraud rules, per-user throttles — is affected on the first request after reload. Roll it out on one backend before the whole frontend if those systems matter.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl reload haproxy

Related

• Request smuggling — the other way a backend can be told something untrue about a request.
• nginx rate limiting — the same trust question, from the limiter’s side.