Metabase needs session and API-key controls that survive a database copy

#zoomeye #metabase #analytics

Metabase needs session and API-key controls that survive a database copy

Metabase turns a database into dashboards and questions that many teams can use. Its application database contains users, sessions, permissions, saved questions, and connector configuration. A copy of that database is therefore sensitive operational material. The security model must cover both the web session path and the credentials that let an API client act without a browser.

At about 23:48 UTC on 29 October 2026, count-only ZoomEye SDK queries with sub_type=all and page size 1 returned 117,274 matches for app="Metabase" and 108,084 for title="Metabase". The app query is the primary observation. These matches are not proof that a session is forgeable or that a deployment is exposed without authentication.

Separate session signing from database access

Metabase's self-hosting guidance calls for a dedicated session secret so that access to the application database alone cannot create usable sessions. Treat that secret as a production credential with backup and rotation procedures. It belongs in a secret store and an environment that the database operator cannot casually read from a shell history or a support bundle.

Test what happens when the secret is missing, changed, or restored from a backup. Existing sessions may become invalid, which is usually desirable after a compromise but disruptive during a routine upgrade. Plan the user notification and reauthentication steps. Do not rotate a key by editing a live process and hoping the application reloads it.

Scope API keys and administrator access

Metabase supports API keys for programmatic requests. A key's identity and permissions are a design choice, not a convenience detail. Use a named service account, restrict its data access, and record the owner and expiry or review date. If the product version supports expiration, test it. If it does not, make rotation a scheduled operation.

The administrator account can change data sources, users, permissions, and settings. Put the administrative interface behind an identity-aware proxy or a trusted network where possible. Require strong authentication and review any password or LDAP fallback. Monitor new administrator creation, changes to session settings, and connector changes.

Use ZoomEye as discovery evidence

A public Metabase fingerprint can be a legitimate customer portal or a forgotten test instance. Resolve the hostname, inspect the TLS certificate, and compare it with cloud and DNS inventories. Do not attempt to log in with guessed credentials or use a public endpoint to test session manipulation. The useful follow-up is to ask which owner controls the route and whether the application database and session secret have the same protection level.

Record the deployment version, database backend, session secret source, API-key policy, authentication methods, backup retention, and logging destination. If an API key is used for an embedded dashboard, document the data it can read and the effect of a key leak. An embedded component may have a different threat model from a human analyst.

Test the failure paths

Use a non-production copy with sanitized data. Invalidate a session and confirm that it stops working. Revoke an API key and verify that the next request is rejected. Change a user's group and check whether data permissions update on the next request. Restore the application database from a backup and confirm that old sessions behave as expected. Then inspect logs for the user, action, object, and result without recording secrets.

Backups and support exports should be encrypted, access-controlled, and tested for restoration. Deleting a user in the live application does not necessarily remove copies in a database backup, an analytics export, or a debugging bundle. The session and key lifecycle must extend to those copies.

Make a reviewable decision

The right configuration depends on who uses Metabase and how much data sits behind it. A small internal deployment can use a private network and strong SSO. A customer-facing portal needs stricter separation, rate limits, tenant checks, and a response plan for exposed API keys. In both cases, the team should be able to explain where the session secret lives, who can create API keys, and how a copied application database is contained.