Why are clients allowed to spoof the X-Forwarded-Port header?

Questions / Help
1

I was debugging some issues with proxy headers in my app, and I stumbled across this snippet in the runtime environment docs:

X-Forwarded-Port
Original connection port: This header may be set by the client [emphasis added] and should denote the port that the client set out to connect to.

I tested it and confirmed that the client can indeed override the X-Forwarded-Port that the fly edge proxy normally populates.

Is this behavior intentional?

I can’t understand the purpose of it. The edge proxy knows what port the client connected to, right? At best, the client is redundantly telling the server information it already knows. At worst, the client is sending an incorrect X-Forwarded-Port value that doesn’t match the port it actually connected to. It seems like it increases the chances of a security vulnerability in the backend app, as it would be easy for an app to treat X-Forwarded-Port as a non-spoofable header.

2

The quick answer is, it’s somewhat common to run Fly apps behind a CDN of some kind. The x-forwarded- headers behave differently, though. x-forwarded-for supports appending IPs to the previous header. The others don’t.

The behavior is intentional but it’s not ideal. :slight_smile:

3

Got it, thanks!