Zipkin's architecture documentation states that there is no built-in authentication in the UI. The UI queries the Zipkin API to search traces and render service maps, spans, timing, and errors. That makes Zipkin an observability service with a clear access-control requirement: if the UI is reachable, the operator must provide the missing authentication and authorization at another layer.
On 13 November 2026 at 03:46 China Standard Time, a ZoomEye count-only query with sub_type=all, page 1, and page size 1 returned 39 matches for title="Zipkin" and 559 matches for app="Zipkin". The inversion is useful. A custom UI or proxy may change the title, and many instrumented applications can mention Zipkin without exposing the server UI. The application fingerprint caught a larger candidate set in this observation, but neither count proves that a particular endpoint is unauthenticated.
The API is the security boundary
The Zipkin UI is a client of the API. Protecting the HTML page while leaving the search or trace endpoints reachable is not a complete control. A caller who knows the API can query the same data without loading the UI. The inventory should list the UI path, the API paths, the query service, and any storage or collector endpoints that belong to the deployment.
Zipkin traces can include endpoint names, service names, span names, timestamps, durations, error tags, and sometimes request metadata. Even without credentials or payloads, the pattern can reveal internal architecture, deployment changes, dependency relationships, and failure paths. A trace search can also be used to enumerate service names and test whether a particular request appeared.
Authentication at a reverse proxy should be tested end to end. The proxy must validate the identity before forwarding to the backend and must not trust a client-supplied identity header. A proxy health route, a debug route, or an alternate backend port can bypass the policy. If the deployment uses network allowlists, verify that the collector and UI share the intended boundary or have separate policies.
Inventory the deployment as two planes
The collector plane receives spans from instrumented applications. The query plane serves searches and the UI. They may run in the same process or in separate services depending on the deployment. Record each listener, its protocol, its authentication control, and the identities that can reach it. A collector that accepts unauthenticated spans from a broad network can be abused to inject misleading traces or consume storage. A query plane that accepts unauthenticated searches can disclose real traces.
Limit what the collector accepts. Use a network boundary or an authenticated gateway where appropriate. Validate the size and rate of ingested spans and monitor for sudden changes in service names or trace volume. Those controls do not replace trace authorization, but they reduce the risk of a public collector becoming a low-cost data pollution path.
For the query plane, test an unauthenticated search against a harmless query. The expected result should be a denial at the proxy or application layer, not an empty UI page with an open API behind it. Then test a low-privilege identity and confirm that it cannot query services outside its intended scope if the deployment supports that separation. If the deployment has no per-service authorization, document the network-level trust boundary and the people who can query the whole trace store.
Make the observation useful without overstating it
The 559 application matches are a product-level discovery signal. The 39 title matches are a narrower page-title signal. Neither is a count of unauthenticated Zipkin servers. Validate an owned match with the response and the deployment record. Then inspect the proxy and backend configuration with secrets removed.
Monitor route changes and ingestion changes. A new ingress for the UI, a second query port, or a collector exposed during a migration can change the boundary without changing the Zipkin version. Keep a snapshot of the expected listeners and compare it with the running service.
Zipkin is designed to be operated behind controls that the product does not provide in the UI. The useful security claim is therefore architectural: identify the API, place it behind an authenticated boundary, restrict ingestion, and test both the UI and the API. The search count helps find candidates for that work; it does not decide whether the boundary exists.
Query evidence
Search:
title="Zipkin"Application:
app="Zipkin"Scope:
sub_type=all, page 1, page size 1Counts: 39 and 559
Observed: 2026-11-13 03:46 China Standard Time