Apache Superset embedded dashboards

Per-customer isolation is the highest-risk part of embedding Superset dashboards, so it must be enforced in Superset's data access layer. The host application's UI can hide rows, but a viewer who reaches a query path outside that UI can still read another customer's data. Each guest token or embedded session needs a scope that Superset evaluates when it runs a query, and that scope must filter the rows the viewer can see. Every dataset that feeds a shared dashboard must be covered by a rule, because one uncovered dataset is enough to expose data across tenants.

Row-level security rules in Superset attach a filter condition to a dataset and apply it to specific roles or to the identity carried by an embedded session. Your design work is to decide how the tenant identifier travels from your application into that scope, whether each customer maps to a value in a tenant column, and what happens when the identifier is missing or malformed. The safe default is to return no rows when the scope is absent. Before you design the scope model, confirm the exact row-level security and guest token claim mechanics in the embedding documentation for your Superset version, since these details differ between releases and determine what you can express.

Four failure modes account for most cross-tenant exposure. The first is a dataset missing a filter: a chart on a second dataset in the same dashboard shows all rows because no rule was attached to it. The second is a cached result shared across tenants, where a query result is reused for a different viewer because the cache key does not include the scope. The third is a chart that bypasses a filter, for example a virtual dataset written in SQL that joins a table without the predicate, or a chart built on a dataset that was never added to the dashboard's rules. The fourth is a role with broader access than intended, such as an embedded role that also inherits access to other datasets or to SQL Lab.

Plan a test matrix before go-live. Create at least two test tenants with distinct, synthetic data, and check every chart on every embedded dashboard from each tenant's session. Compare results against a direct query on the source with the filter applied, and repeat the check after cache expiry and after any dataset or role change. Review the roles assigned to embedded sessions and remove permissions they do not need. Ask any implementation partner to include this test matrix, the cache review and the role audit in the written scope, because they take time that is easy to underestimate and must be repeated whenever dashboards change.

The most important check for embedded Superset is whether a guest token issued for one customer can ever reach another customer's data. Treat isolation as a claim to be disproven, not assumed from configuration. Build a test plan that tries to break the boundary in the ways an attacker or a careless integration would, then run it against every change that touches the embedding service, the row-level security rules, or the Superset version. The tests below are the minimum set we would expect a team to own before a customer-facing dashboard goes live.

Start with cross-tenant tests. Create two test tenants with distinct row-level security clauses on the same dataset, then request a guest token scoped to tenant A and use it against tenant B's embedded dashboard ID and its underlying chart data endpoints. The expected result is zero rows or an authorization error, never a partial result. Repeat the test with tenant A's token against a dataset that tenant B owns directly, because embedding a dashboard does not automatically restrict the datasets its charts query. Also test expired tokens and tokens whose payload has been edited or re-signed with a wrong key. Each should be refused. Confirm the token lifetime and signing key handling with your own embedding service configuration, since those settings live outside Superset's default install.

Next, test origin and filter controls. Load the embedded dashboard from a page on a domain that is not on your allowed list and confirm the embed is refused. Then test the chart-level controls a user can reach: native filters, drill-to-detail, cross-filtering, and any exposed sort or column selectors. For each, try to widen a filter, remove a filter that the token applied, or reference a column the row-level clause does not cover. Record which controls can alter the query and whether the rule still applies. Finally, check caching. Run the same chart for two tenants in sequence and confirm that the second tenant receives its own rows, not the cached result of the first. Test this with the caching layer enabled, because results can be shared under a key that does not include the tenant identity.

Failure behavior needs the same rigor as the success path. When a token is refused, the dashboard should show a clear error or an empty state, and it must not fall back to an unfiltered query or show another tenant's data during a retry. Test this by forcing each failure: expired token, missing filter claim, database timeout, and an unreachable cache. The backend should log every refused request with enough context to investigate, including the request time, the dashboard identifier, the origin, and the reason for refusal, without writing the token itself to logs. Confirm that these log entries reach your central logging system and that someone is alerted when refusals rise sharply. Ask your implementation partner to show you where each of these events appears in your environment.

Turn the plan into a repeatable test suite and run it in staging before every Superset upgrade. Superset release notes and the upgrade guide ask teams to back up the metadata database, run the migration commands, and check UPDATING.md for breaking changes before promoting a new version. Add the isolation suite to that sequence so that a version change cannot silently weaken row-level security or caching behavior. Store the tests as code, version them with the embedding service, and keep the results as evidence for your own security review. Independent auditors may later ask for this evidence, but DeployOpen prepares the tests and records only; it does not issue audit conclusions.