DEV Community

kozhevniko
kozhevniko

Posted on

Uptime Kuma status pages and metrics need separate access rules

#security #defensivesecurity

Uptime Kuma status pages and metrics need separate access rules

Uptime Kuma monitors services and can publish status pages for users outside the operations team. It also exposes a Prometheus metrics endpoint and an authenticated administration interface. Those surfaces have different audiences and different data.

The count-only ZoomEye measurement on 2026-11-09 at 06:47 Asia/Shanghai used sub_type=all, page 1 and page size 1:

  • app="Uptime Kuma": 589,512
  • title="Uptime Kuma": 77,830
  • http.body="Uptime Kuma": 898,554

The app count is large because the product is popular and can appear in many environments. The app query is a discovery scope, not a vulnerability count. The title and body differences show that a single fingerprint will miss or over-count parts of the deployed population.

Three surfaces, three policies

The admin console can create monitors, edit notifications and change users. A public status page may intentionally show service names and incident history. The metrics endpoint can reveal monitor names, response times and availability. Separate the routes, hosts and authentication policies.

Use a management host or VPN for the admin console. Publish only the status page through the public reverse proxy. If Prometheus runs in a private observability network, keep /metrics on that network and require an API key where the Uptime Kuma version supports it.

Metrics keys are credentials

Uptime Kuma's API key documentation explains that adding the first API key switches the metrics endpoint away from basic authentication. The key is used with a username and the key as the password in the documented example. Treat it as a service credential, not a public status token.

Store the key in the monitoring system's secret store. Limit who can read the configuration and rotate the key when an operator leaves or a scrape target changes. Monitor failed authentication and unexpected scrape sources.

Status-page content

A public status page can disclose customer names, internal service topology and incident timing. Review the monitor names and descriptions as user-facing content. Keep private monitors on a separate page. If the status page has an incident feed or API, test whether it reveals drafts, private comments or admin notes.

Do not rely on search-engine suppression as the only visibility control. A public URL can be copied and indexed elsewhere. Use authentication for anything that is not intentionally public.

Review checklist

  1. Request the admin console, status page and metrics route from an untrusted network.
  2. Confirm that only the intended public route is reachable.
  3. Verify API key authentication for metrics after the key is enabled.
  4. Search public status content for internal hostnames and customer data.
  5. Test account removal and session revocation.
  6. Confirm that notification credentials are not visible on public pages.

The large observed population makes naming and route discipline important. Uptime Kuma can provide useful public status information without exposing the monitoring control plane. Separate the admin, status and metrics surfaces, then verify each one with the same network and identity tests.

References

Top comments (0)