Zoraxy deployments need route-level authentication, not just a hidden admin page
Zoraxy is a general-purpose HTTP reverse proxy with a web management interface and per-route access options. The useful security question is not whether the management page is hard to guess. It is whether every proxied hostname, alias and path reaches a backend through an intended authentication decision.
The project documentation describes basic authentication, forward authentication, OAuth2 and ZorxAuth as available authentication methods. It also documents a no-auth mode for deployments that already have permission management in an upstream proxy. The README warns that no-auth should be used only in a trusted environment or behind another authentication proxy. That warning turns the reverse proxy configuration into part of the identity boundary.
Measurement evidence
On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned zero matches for app="Zoraxy", 5,863 for title="Zoraxy" and 20,084 for http.body="Zoraxy". These are discovery observations, not counts of exposed management panels or deployments without authentication. Body matches can include documentation, articles and marketing pages, while the title query remains a broad contains match.
The low application fingerprint is useful as a caution. A product name in a title or body is a lead that needs ownership and service validation before it becomes an inventory record.
Map every route
Record the public hostname, path prefix, upstream address, TLS mode, authentication provider, allowed groups and bypass rules for each route. Test direct access to the upstream service from a network that should not reach it. A proxy can enforce authentication while the backend remains reachable on a separate port.
Review aliases and default routes. An alias intended for a temporary service can continue forwarding after the service moves. Check whether a path-based rule can match a different backend than the operator expects, and whether forward-auth headers are stripped from client requests before the gateway adds trusted values.
Secure the management plane
The route policy and the management UI are different control planes. Restrict the UI to a management network, require strong authentication and separate administrator identities from ordinary proxy users. Back up the configuration after review and protect any stored provider secrets. Do not use no-auth mode as a shortcut when the upstream proxy cannot prove the user identity.
Monitor changes to routes, auth providers and access rules. After an unexpected exposure, disable the affected route, preserve configuration and access logs, rotate provider secrets and test the backend again from outside the approved network.
Top comments (0)