Grafana Mimir tenant headers require an authenticating proxy

Grafana Mimir stores and queries metrics at scale. It also supports multi-tenant operation through the X-Scope-OrgID header. That header is part of the request contract, not a substitute for authentication. A public Mimir endpoint can be a serious data exposure if the deployment expects clients to set a tenant identifier and has no trusted gateway to enforce it.

Measurement and scope

On 2026-11-11 at 23:48 UTC, ZoomEye returned 1,075 matches for title="Grafana Mimir" with sub_type=all, page 1, and page size 1. The same probe returned 0 for app="Grafana Mimir" and 1,150 for http.body="Grafana Mimir".

The title result is useful because it names the product directly, but it does not describe the deployment mode. Mimir can be a single binary, a distributed cluster, or a managed service with an external gateway. A login page, documentation mirror, or monitoring path may appear in the results. The count should be compared with approved domains and expected exposure.

Why the header matters

Grafana's Mimir documentation says the tenant ID is taken from X-Scope-OrgID on each HTTP request. The authentication guide says teams must add a protection layer such as a reverse proxy that authenticates requests and injects the appropriate tenant ID. It also supports multiple tenant IDs separated by a pipe for federated queries.

If a client can choose the tenant header directly, the application must show that the client is authorized for every tenant it requests. The reverse proxy should strip any client-supplied value and add the value derived from the authenticated identity. It should reject requests with missing or malformed tenant identities. The Mimir service should not be reachable from networks that bypass the proxy.

Data and availability risks

A metrics store contains more than CPU graphs. It can reveal service names, deployment timing, error rates, queue depth, host labels, and sometimes URLs or user identifiers in labels. Cross-tenant reads can disclose operational patterns or business activity. Cross-tenant writes can pollute another team's data or create a denial-of-service condition through high cardinality.

The HTTP API also includes administrative and operational paths. A public endpoint may expose health, configuration, or query behavior even when tenant data is protected. Review the full route surface and the proxy's path allowlist. Do not expose the query frontend, distributor, or alertmanager administrative paths to the internet without an explicit requirement and a compensating control.

Review steps

Inventory every Mimir entry point and the gateway in front of it. Confirm that the gateway performs authentication, validates tenant membership, strips untrusted X-Scope-OrgID values, and writes an audit event. Test a request with no header, a valid header, and a header for a tenant the caller does not own. Test the same path through every ingress and load balancer.

Check whether multi-tenancy is enabled. If it is disabled, the service may use an anonymous tenant internally, but that does not mean the endpoint is safe to expose. Review remote-write endpoints separately because they accept data and may have different authentication assumptions from query endpoints.

Use the ZoomEye count as a discovery signal for public product pages, then validate ownership and routing. Do not conclude that every Grafana Mimir title is a public metrics API. The useful outcome is a shorter list of endpoints that need gateway authentication and tenant isolation testing.

References

• Grafana Labs, Grafana Mimir authentication and authorization
• Grafana Labs, Grafana Mimir HTTP API
• Grafana Labs, Grafana Mimir architecture
• ZoomEye query: title="Grafana Mimir"