9router /v1 APIs has unauthenticated access via reverse proxy locality collapse

Summary

9router treats local loopback requests as trusted and allows access to /v1/* without an API key. In a documented/common reverse-proxy deployment where nginx forwards public traffic to the backend via 127.0.0.1, external non-Origin requests are misclassified as local. This allows unauthenticated access to /v1 APIs such as /v1/models, and may allow abuse of configured upstream provider credentials depending on the enabled providers.

Details

• Affected version / commit: 9router v0.4.80 @ b282f05.
• Deployment precondition: a same-host reverse proxy (e.g. nginx) forwarding public traffic to the backend on 127.0.0.1 / localhost. This mirrors the documented cloud deployment (proxy_pass http://localhost:20128 with X-Real-IP / X-Forwarded-For).
• Observed behaviour:
  • The direct backend (direct-backend, port 18081) returns 401 for /v1/models without an API key.
  • A direct request that spoofs X-9r-Real-IP: 127.0.0.1 still returns 401: the custom server deletes the client-supplied header and overwrites it with the real socket address, so naive header spoofing does not work against the direct backend.
  • The proxied path (reverse-proxy, port 18080) returns 200 with the full model catalog for the same /v1/models request without any API key.
  • A proxied request that carries an Origin header returns 401. The bypass therefore primarily affects curl / SDK / server-side / non-browser clients, which do not send Origin.
• Root cause: the backend's local/remote decision relies on perceived socket/loopback locality after reverse proxying. Because nginx connects to the backend from 127.0.0.1, the backend stamps a loopback client address for every internet client and treats the request as local, skipping the /v1 API-key requirement. The forwarded X-Real-IP / X-Forwarded-For headers that carry the true client IP are ignored for this decision.