Metabase Security Review

Metabase’s own documentation confirms one embedding secret key is shared across every static and guest embed an instance publishes, so whoever holds that key can reach every embedded dashboard and question, not just one.

Why Metabase security comes down to the permission graph and a single embed key

Metabase’s data permissions documentation sets out five View data permission levels on Pro and Enterprise plans, Can view, Granular, Row and column security, Impersonated and Blocked, applied per database, schema or table. Blocked is stricter than it first looks: the same page confirms it makes collection permissions insufficient to view a question that touches that data source, and that blocking even one table disables native, hand-written SQL queries against every table in that database for the group, because Metabase cannot parse SQL to confirm which tables a query actually reaches. Download permissions follow the same logic, offering No, Granular, 10 thousand rows or 1 million rows options, but native query downloads are only allowed where a group holds download permission across the whole database. We map every group’s actual level against what the business meant to grant, since a Granular or Blocked setting that looks tight at the table level can still leave native queries and downloads wider open than intended.

Row and column security filters data using person-level user attributes, and Metabase’s own row and column security documentation is explicit that the user attribute value must be an exact, case-sensitive match for the filter value, otherwise the person gets an empty result rather than their own data. A simple row filter can only restrict rows by a single column, while a custom SQL-based question can restrict rows across multiple columns and also restrict or edit which columns are returned, the same distinction between row-level and object-level restriction we test on our Tableau security review. We test which mechanism actually protects each sensitive table, and whether a mismatched or missing user attribute has quietly broken a filter rather than being caught before launch.

Access into Metabase from outside the permission graph carries its own risk. An API key is created against a named Group and Metabase’s API keys documentation confirms the key carries exactly that group’s permissions, shown in full only once at creation. Static and the newer guest embeds both sign requests with a JSON Web Token, and Metabase’s own guest embedding documentation states that secret key is shared across every embed the instance creates, and that because a guest embed carries no real user session, it cannot enforce row and column security at all, recommending Modular embedding with SSO instead wherever per-viewer restriction matters. We test who holds that shared key and every live API key’s group binding.