@jamesarosen it looks like we shouldn’t “trust proxy” right now!
Did you get round to writing your Fly-
→ X-
express middleware? Sounds like that would be a good hack for now, although careful not to enable it when not running on fly, as presumably that could introduce the same problem in reverse
Fly subtly document at Public Network Services · Fly Docs that X-Forwarded-Port
cannot be trusted, but don’t mention that the rest of the headers can be spoofed. This looks like a real problem to me. Perhaps more clearly documented by modifying your example like so:
$ curl -sv \
-H "Host: injected.host" \
-H "X-Forwarded-Proto: https" \
-H "X-Forwarded-For: 1.2.3.4" \
-H "X-Forwarded-Port: 443" \
-H "X-Forwarded-Ssl: on" \
http://debug.fly.dev/
...
=== Headers ===
Host: injected.host
Fly-Forwarded-Proto: http
Fly-Forwarded-Port: 80
X-Forwarded-Proto: https
Fly-Client-Ip: (my personal IP address)
Fly-Request-Id: 01GH5YR86ZVDQTGYD6YKB14WQB-sin
Fly-Forwarded-Ssl: off
X-Forwarded-Port: 443
X-Forwarded-Ssl: on
X-Forwarded-For: 1.2.3.4, 188.93.151.254
...