Metabase Setup and API Surfaces Need More Than a Title Search

Metabase, a reporting portal, is commonly exposed as part of a deployment. The login page is just one component. The initial administrator is created during the setup flow, API keys support automation, and SCIM provisioning connects identity providers to user and group management. A thorough inventory of Metabase's surfaces is necessary beyond a mere title search.

The presence of the product does not guarantee the availability of setup, API, or provisioning endpoints without proper authorization. Using ZoomEye, 117,591 app queries, 108,386 title queries, and 196,775 HTTP body queries were collected on November 8, 2026. These counts suggest that both app and title queries are valuable signals, while the HTTP body query is broader and may include documentation, dashboards, reports, and pages referencing Metabase without actual execution.

The Metabase API documentation outlines a setup flow where a setup token is retrieved from GET /api/session/properties and the first admin is created via POST /api/setup. This procedure occurs during the first installation. The critical question is whether an instance remains in an incomplete state or reveals setup metadata after deployment.

The team must verify the setup state through an authorized administrative path, document the result, and ensure that subsequent admin creation is disabled. API keys, created under Admin settings and authentication, must be managed with an owner, purpose, and rotation date. Unused keys should be removed, rotated post staff changes, and avoided in dashboard queries or client-side code.

Directly printing the key fragment in an incident ticket is prohibited. SCIM, another management surface, includes an endpoint and a token that can be regenerated. Group and user provisioning can alter access at scale. Confirm which identity provider manages the token, examine whether deprovisioning events reach Metabase, and determine if an emergency local admin remains available.

A valid token not linked to a supported integration is a cleanup issue, not a reason to disable provisioning without a replacement plan. An external inventory should align Metabase with DNS, certificate, cloud, and application ownership data. Verify the host's role as an internal reporting service, customer portal, or marketing site.

Examine TLS and response headers before transitioning to authorized configuration review. Avoid creating a setup user, calling API endpoints with guessed credentials, or enumerating tenant data during the review. The count differences aid in planning sampling. The app query provides a product-centric population, the title query offers a page-title population that may include unverified deployments, and the HTTP body query is a wide net not to be treated as a definitive list.

Each group should be sampled, ownership confirmed, and the observed host compared to the internal reporting catalog. Metabase's value lies in making data accessible. Its setup, API, and provisioning surfaces are integral to that value. The exposure review must confirm that each surface has an owner, authentication rule, and lifecycle.