vertx-web
vertx-web copied to clipboard
Add list of trusted origin IP's for `Forward` http header
We have real ip feature but lack configurable list of IP addresses of trusted origins of Forwarded http header.
I found ticket where problem pretty well described. I totally agree with this comment. However there's interesting situation.
Problem
I have vertx application behind cloudflare proxy (used for mitigating DDOS attacks):

Also there's couple of enterprise clients who refuses to send requests via cloudflare for their own policy and security reasons. They wanted direct connection to my infrastructure:

And there's problem. I need to know real IP of clients behind cloudflare and also want protect myself from potential tampering of IP address by directly connected users.
My current solution is place nginx reverse proxy in between:

Nginx strips any forwarding headers from client and put its own headers.
Involving nginx just for sanitizing couple of http headers is tedious and places unnecessary maintenance burden.
Proposal
Add several options to the HttpServerOptions class:
trustedForwardOrigins- list of individual IP addresses (1.2.3.4, 2001:db8::1) and CIDR networks (1.2.3.4/24, 2001:db8::/32)forwardHeaders- one ofAllowForwardHeadersenum values with addition of new value namedCUSTOM_HEADERcustomForwardHeader- name of http header where real IP address resides ifforwardHeadershasCUSTOM_HEADERvalue
CUSTOM_HEADER and customForwardHeader are not strictly necessary and needs to be discussed. Cloudflare uses nonstandard CF-Connecting-IP and True-Client-IP in addition to X-Forwarded-* http headers. Eventually cloudflare may implement rfc7239. But there may be other proxy services and software with their own bizarre forwarding headers. For example I personally saw X-Real-IP header in real use.
Algorithm of resolvilng IP:
- If
trustedForwardOriginsis null or empty, then we trust forwarding headers from everyone. - If request comes from IP that is listed in
trustedForwardOrigins, then process forwarding headers. - If request comes from IP that is not listed in
trustedForwardOrigins, then forwarding headers totally ignored.
That's how nginx realip module works.
Proposed options may be added to Router interface. But I have seen that the real IP functionality is always configurable at the server-wide level. Not per-route.