Metabase Setup and API Surfaces Need More Than a Title Search

Metabase is often exposed as a reporting portal. The visible login page is only one part of the deployment. The setup flow creates the first administrator, API keys can be created for automation, and SCIM provisioning can connect an identity provider to user and group management. A public Metabase host deserves an inventory that covers those surfaces beyond a title match. The existence of the product does not prove that setup, API, or provisioning endpoints are available without authorization.

For this assessment, ZoomEye count-only queries were collected on November 8, 2026 using sub_type=all, page 1, and page size 1. app="Metabase" returned 117,591. title="Metabase" returned 108,386. http.body="Metabase" returned 196,775. The application and title counts are relatively close, which makes both useful candidate signals. The body count is broader and may include documentation, dashboards, reports, and pages that mention Metabase without running it.

Metabase's API documentation describes a setup flow that reads a setup token from GET /api/session/properties and creates the first admin through POST /api/setup. That flow is expected during first installation. The security question is whether an instance remains in an unfinished state or exposes setup metadata after commissioning. A team should check the setup state through an authorized administrative path, record the result, and confirm that subsequent admin creation is disabled.

API keys need a separate inventory. Metabase documentation places API key creation under Admin settings and authentication. A key can support automation, but it should have an owner, a purpose, and a rotation date. Review whether keys are scoped to an account with more access than the integration needs. Remove unused keys, rotate after staff changes, and avoid placing them in dashboard queries or client-side code. Do not print the key fragment in an incident ticket.

SCIM is another management surface. The documentation describes a SCIM endpoint and a SCIM token that is shown once and can be regenerated. Group and user provisioning can change access at scale. Review which identity provider owns the token, whether deprovisioning events reach Metabase, and whether an emergency local admin remains available. A token that is valid but no longer tied to a supported integration is a cleanup finding, not a reason to disable provisioning without a replacement plan.

The external inventory should compare the Metabase candidate with DNS, certificate, cloud, and application ownership data. Verify whether the host is an internal reporting service, a customer portal, or a marketing site. Check TLS and response headers, then move to authorized configuration review. Do not attempt to create a setup user, call API endpoints with guessed credentials, or enumerate tenant data.

The count differences also help plan sampling. The app query gives a product-oriented population. The title query gives a page-title population that may include deployments missed by the app fingerprint. The body query is a broad net that should not be treated as a list of exposed Metabase instances. A team can sample each group, confirm ownership, and compare the observed host with the internal reporting catalog.

Metabase's value comes from making data accessible. Its setup, API, and provisioning surfaces are part of that value. The exposure review should verify that each surface has an owner, an authentication rule, and a lifecycle. A product count starts the inventory. It does not replace the setup state and token review.

Query evidence

• Collection: 2026-11-08 00:44 UTC, ZoomEye SDK, sub_type=all, page 1, page size 1.
• app="Metabase": 117,591.
• title="Metabase": 108,386.
• http.body="Metabase": 196,775.

References

• Metabase: Set up from code with the API
• Metabase: User provisioning with SCIM
• Metabase: Agent API and authentication
• ZoomEye app query
• ZoomEye title query