How guest tokens and row level security keep one customer's data out of another's dashboard
When a product team embeds Superset dashboards for many customers, one embedded dashboard can serve every tenant, and what each viewer sees is decided at request time. Guest tokens carry the resources and RLS clauses that scope a viewer, and your backend must mint them. The browser never decides which tenant a viewer belongs to. Your server authenticates the end user in your own application, works out the tenant and the allowed dashboard, and then requests a short-lived guest token from Superset with the row level security clauses for that viewer. The embedded SDK in the page only passes that token along.
Teams need this model when the viewers are customers of your product rather than employees with their own Superset accounts. Creating a Superset login for every end user adds account administration, role sprawl and a login experience you do not control. A guest token lets your existing session decide access while Superset enforces the row filters. The trade-off is that you now own part of the security boundary: if your backend passes the wrong clause, Superset will faithfully apply it. Confirm in the Superset documentation for your release how guest tokens, guest roles and RLS clauses are represented in the request, because these field names and behaviors change between versions.
This feature is configured in two places that must agree. In Superset, the dashboard must be enabled for embedding, the guest role must have access to the right datasets, and the RLS rules must be defined against the tables that hold tenant data. In your host application, the backend must build the same filter for each request. A mismatch, such as an RLS rule keyed on a column the token does not match or a dataset missing from the token's resources, is the most common source of cross-tenant exposure. Assign one owner for each side, write the expected filter for each tenant in a test fixture, and treat any change to either side as a change that needs a leak test before release.
Guest token and RLS options and when each fits
This table compares the RLS and guest token options that decide what an embedded viewer can see, and when each fits a shared-table model or a per-customer schema. Read each row as a control with a known limit, and pair it with the control that covers the gap in the last column. The main takeaway is that guest tokens control which dashboard opens, while RLS controls which rows come back from the database.
| Option | What it scopes | Fits best | What it cannot enforce |
|---|---|---|---|
| RLS rule bound to selected datasets | Filter clause applies only to the datasets you select | Dashboards built on a few known datasets with a tenant column | Datasets added later stay unfiltered until someone adds the rule |
| RLS rule with no dataset selected | Clause applies across datasets that expose a matching column, confirm the behavior in your version | Shared tables with one consistent tenant column name everywhere | Same-named columns with different meanings, so test every dataset |
| Guest token with a dashboard resource | Token grants access to one dashboard identifier | Embedding one dashboard per customer view in a shared-table model | Does not restrict queries outside the dashboard, so RLS is still required |
| RLS clause supplied in the guest token | Filter your backend signs into the token when it is issued | Tenant values taken from the authenticated server session | A clause built from client input can be changed, so build it server-side |
| Short token lifetime | Token expires after the configured number of seconds | Long embedded sessions where your backend refreshes tokens | Does not revoke a token already issued, so a leaked token works until expiry |
| Long token lifetime | Fewer refresh calls and a wider window for misuse | Low-risk internal or demo embedding with no customer data | Cannot cut off a departing customer's access before expiry |
| Shared table with RLS only | One table, filtered by a tenant column | Large tenant counts with a uniform schema and strong testing | Misconfigured datasets, raw SQL charts or unrestricted roles can bypass it |
| Per-customer schema or database | Separate physical datasets, with RLS as a second control | Tenants that need separate storage, retention or audit boundaries | Dashboard owners can still point charts at other schemas if roles allow it |
Setting up guest tokens and RLS in order
This sequence turns a Superset dashboard into a tenant-scoped embed, starting with the guest role and dataset access and ending with a two-tenant isolation test. Each step closes with a check, so a data leak is caught in staging before any customer sees the dashboard.
Enable embedding and the guest role
Turn on embedded dashboards in your Superset configuration and set a SECRET_KEY, which the configuration documentation requires before the instance starts. Create the guest role that embedded viewers will hold, and give it read access only to the datasets behind the embedded dashboard. Confirm the exact configuration keys and feature flag names for your release in the configuration documentation before you change them. Done means the dashboard loads from a test page with a guest token, and an anonymous browser session cannot open it directly.
Add the tenant column to each dataset
In the warehouse, add a tenant identifier column to every table or view the embedded dashboard reads, and populate it from your system of record. Create a read-only database user for Superset with access only to those objects. If a dataset has no tenant column, decide with the data owner whether it can be embedded at all, because RLS can only filter on columns that exist. Done means a query for one known tenant run directly against the warehouse returns only that tenant's rows.
Define RLS rules on each dataset
In Superset, create a row level security rule for each dataset that needs tenant scoping. Write the clause against the tenant column and attach the rule to the guest role so it applies to embedded viewers. Record which datasets each rule covers, and avoid rules that apply to every dataset unless every dataset really has the tenant column. Done means a list of rules shows each embedded dataset has a rule attached to the guest role, with no rule applied to a dataset it was not written for.
Test RLS as a guest user
Load the dashboard as a guest user in staging with a token carrying one test tenant's identifier. Compare each chart's totals with the warehouse query for the same tenant. Then exercise every filter viewers can change, including drill-down, cross-filters and any chart with custom SQL, because a control that skips the RLS clause is a leak path. Done means every chart matches the warehouse count for that tenant and none shows rows from another tenant.
Mint short-lived tokens from your backend
Have your backend request the guest token after it authenticates the end user, so the tenant identifier comes from the server-side session and never from the browser. Limit the token's resources to the one dashboard identifier it needs, add the RLS clause for that tenant, and set a token lifetime your team agrees on in writing. Refresh tokens through the backend when they expire. Done means a decoded sample token in staging shows only the expected resource and clause, and a request with a modified tenant value is refused.
Verify isolation with a second tenant
Create a second test tenant with different rows and open the same dashboard with its token next to the first. Compare every chart, filter option and export for both tenants, and confirm no value from one appears in the other. Include negative tests such as an expired token, a token for a different dashboard and a tampered clause. Rerun the full set after each dataset change or Superset upgrade and keep the results as evidence. Done means the test set passes for both tenants.
How tenant filters differ by data model
With one shared table, every tenant's rows sit in the same dataset, so isolation depends almost entirely on the row level security clause. The rule is a SQL expression, typically a comparison between the tenant column and a value the backend supplies, attached to each dataset it should constrain. Your server must place the tenant identifier in the RLS entry of the guest token it signs, and the browser must never choose that value. Leaks in this model usually come from configuration gaps rather than from the query engine itself.
- Clause on the wrong column: a rule filters on a name or free-text field that is editable or not unique, so two tenants can match.
- Missing dataset assignment: a new dataset, or a virtual dataset built on the shared table, is created without the rule attached.
- Empty tenant value: a token that arrives without a tenant claim can evaluate the clause in a way that returns more rows than intended, so test that case explicitly.
- Unfiltered paths: charts, SQL Lab queries or saved content on the same table may sit outside the rule that protects the dashboard.
Before release, confirm for your Superset version how a rule with no dataset assignment is applied, then run the same chart with two tenant tokens and compare the row counts against the source table.
With one schema per tenant, the primary boundary moves from the filter into the database objects. Each tenant's tables live in their own schema, and each Superset dataset points at a schema-qualified table for that tenant. Row level security remains useful as a second control, but the guest token's dataset reference now does most of the separating. The backend must therefore send the correct dataset identifiers for the tenant, and the onboarding process must create datasets that match the schema each customer owns.
- Dataset built on a shared schema: a dataset is created against a common schema or view, which exposes all tenants even though each tenant has a schema.
- Default search path: unqualified table names resolve through the database user's default search path, so a query can reach another tenant's objects.
- Broad grants on a shared role: one database role can read every tenant schema, and Superset will use it for every dataset.
- Stale references after changes: a renamed or recreated schema leaves a dataset pointing at the wrong tenant's table.
Ask your team to list every dataset per tenant and confirm that each one resolves to a schema owned by that tenant, then check the database role's grants against the same list.
With one database per tenant, each customer has its own connection, and the strongest boundary is the warehouse account that the connection uses. Superset holds one database connection per tenant, and each tenant's datasets reference only their own connection. The guest token still identifies the dataset, so the backend must map each tenant to the datasets on that tenant's connection and never let a request select a connection on its own. This model keeps data apart at the cost of more connections to manage, rotate and monitor.
- Shared connection reused across tenants: one connection is copied for several tenants during setup, so a single account reads every database.
- Privileged connection account: the connection uses an administrative login, which bypasses the separation the databases were meant to provide.
- Credentials in shared configuration: connection strings for different tenants are stored together, where a change or export for one tenant exposes the others.
- Cached results across tenants: confirm how query result caching is keyed when two tenants use similar queries, and whether the key includes the tenant or connection.
Verify that each connection uses a least-privilege account scoped to one tenant's database, and that a token for tenant A cannot retrieve a dataset attached to tenant B's connection.
Security risks in guest token and RLS design
Guest tokens and RLS rules decide which rows an embedded viewer can see, so a mistake in either one exposes one customer's data to another. The cards below cover the decisions that carry that risk, from how the signing key is held to how the database role is configured.
Protect the token signing key
Your backend signs each guest token with a secret, and anyone who obtains that secret can mint tokens for any tenant. Superset also requires its own SECRET_KEY to start, so keep the two secrets separate, store both in a secrets manager, and limit who can read them. Confirm how rotation works for each key before go-live, since rotating a key can invalidate tokens already in circulation.
Derive tenant identity on the server
A tenant ID sent from the browser or from a query string is attacker-controlled, and changing it should never change what a viewer sees. Your backend should look up the tenant from the authenticated session, then place that value in the guest token's RLS clause. Test this by requesting a dashboard with another tenant's identifier and confirming the response contains no foreign rows.
Keep token lifetime short
A guest token that stays valid for hours keeps working after a customer's user is removed or their contract ends. Issue tokens with the shortest lifetime your embedding flow tolerates, and request a fresh token from your backend when the viewer's session refreshes. Confirm with your team which events, such as offboarding or plan changes, should end access immediately rather than waiting for expiry.
Watch for RLS rules that match nothing or everything
An RLS clause with a typo in a column name or an empty value may match no rows, which breaks dashboards silently. A clause that is missing or evaluates to a true condition can expose every row in the dataset. For each rule, test one tenant with known data, one tenant with no data, and a request with the filter removed, and record the results as evidence.
Limit the database role's privileges
RLS filters apply only to the queries Superset sends, so a database role with broad read access can still reach other customers' tables through a direct connection or a custom SQL chart. Grant the Superset database role access only to the datasets it needs, and confirm that rules attached to a dataset cannot be bypassed through another dataset that reads the same tables.
Test for cross-customer leaks
Scoping rules change as dashboards, datasets and tokens are edited, so a configuration that passed last quarter can fail today. Build an automated test that signs tokens for two tenants with distinct test data, loads each dashboard, and fails the run if any row belonging to the other tenant appears. Repeat the test after every upgrade, dataset change or RLS edit.
How to test for data leaks between customers
The test that matters most is whether one customer can see another customer's rows, so build the plan around that question before you open the embedded dashboard to anyone. Start with two test tenants that have distinct, easily recognized data in the same dataset. Generate a guest token for each tenant from your backend, using the same dashboard resource and the RLS rules you intend to ship. For each token, compare the row count and every chart value against a query you run directly on the source database with the same tenant filter applied. If a chart shows a value that the direct query does not return for that tenant, or any value that belongs to the other tenant, the rule set is wrong and the release stops.
Next, test the boundary a browser can reach. Open the embedded dashboard with tenant A's token, then try to change the filter values, the dataset parameters or the request payloads from the browser developer tools, and replay tenant B's token against tenant A's dashboard. Record which requests succeed and what data they return. Then check the places data can be reused across requests. Confirm whether the caching layer keys cached results by the RLS context, and whether async queries and alerts or reports, which depend on the caching layer and worker components, run under the correct identity. Ask your team to confirm how your installed Superset version handles each case, since the behavior of cache keys and async execution is a version-dependent detail to verify, not assume.
Repeat the full test plan after every Superset upgrade, every change to an RLS rule and every change to the token lifetime settings, and keep the results with the change record. Independent testing can be added as a separate scope if you want a third party to attempt the same cross-tenant access paths, and it should be scoped and agreed in writing before the work starts. The output from these tests is also useful evidence for the access control reviews covered elsewhere in this page.
Limits to confirm in your environment
Guest tokens and row level security behave according to the Superset release you run, the caching layer you configure and the authentication stack around it. The cards below list the behaviors to confirm with the vendor documentation and your own test results before any customer data is exposed through an embedded dashboard.
Guest token API behavior by release
Confirm the exact guest token request format, the claims it accepts, the resource identifiers it requires and how the token is validated in the release you deploy. Superset has moved quickly across major versions, so an example from the current development docs may not match a 6.x installation. Check the upgrade notes for changes to the embedded and guest token flow, and record the version you tested against in your build documentation.
RLS rules and dataset scope
Confirm how an RLS rule is applied when it is attached to a guest token and whether it behaves differently for datasets that are not listed in the token resources. Test a rule that references a tenant identifier against charts that query the same dataset from different dashboards, because a rule that appears to filter one chart may not filter a saved query or a chart built on a virtual dataset. Document which datasets are reachable by each token type.
Caching layer and per-viewer results
Confirm whether cached chart results and query results are keyed by the RLS filter applied to each viewer, not only by the chart and dataset. If the cache key omits the tenant filter, one customer can receive another customer's cached rows. Check the caching configuration in your release, the cache timeout you set and whether async queries and thumbnails reuse results across viewers. Test with two tenants requesting the same chart within the cache window.
Worker and thumbnail behavior
Confirm whether alerts, reports, async queries and dashboard thumbnails run under the viewer's guest context or under a service account. A worker that renders a thumbnail or scheduled report without the tenant filter can produce output that is cached or emailed to the wrong recipient. Confirm which components require the caching layer and Celery workers in your deployment, and confirm that no embedded dashboard depends on a background job that runs without the token context.
Authentication and token signing
Confirm how the host application authenticates its own users, how it requests guest tokens from its backend and which secret or key signs those tokens. Confirm the token lifetime the release enforces and whether the host can shorten it per request. Check how SECRET_KEY rotation with PREVIOUS_SECRET_KEY interacts with tokens already issued, since a rotation can invalidate sessions or change how signed material is verified.
Operator and Helm chart maturity
If you run Superset on Kubernetes, confirm which deployment method your release documents. The official Helm chart is marked deprecated in current development documentation, and the Kubernetes Operator is in alpha with a v1alpha1 API whose schemas may change between releases. Record which method you use, how configuration for guest token settings is passed through it, and how you will test those settings after each upgrade.
Questions teams ask before building guest token RLS
What drives the cost of building guest token RLS for embedded Superset?
The cost is driven by how many distinct access rules you need, how many datasets they touch, and how much of the surrounding application must change. Each dataset that needs tenant filtering, each role that sees a different slice, and each embedded dashboard that mixes datasets adds design and test work. Your backend token service, the authorization model behind it and your existing identity setup add further work. A written scope should list the datasets, the rule set, the token issuing code and the leak tests separately, so you can compare a partner quote with your own team's estimate line by line. Superset itself is Apache-2.0 licensed with no paid edition, so software licensing is not a cost line here. Ongoing costs usually come from upgrades and re-running tests after changes to datasets or dashboards.
How long does a guest token RLS build take?
Duration depends on the number of datasets, the complexity of the tenant model and whether the Superset environment already runs in production. No duration figure is supplied for this work, so ask any partner, including DeployOpen, to state a timeline in the written scope, with the phases and the inputs each phase needs from you. A sensible plan separates the design of the rule model, the token service, the staging environment with realistic but non-production data, and the cross-tenant leak testing. Most delays come from late decisions about which tenant identifier is authoritative and from datasets that were never reviewed for sensitive columns. Confirm the schedule against your release calendar, especially if you need a staging upgrade first.
What does our team have to provide for the engagement?
The client team must supply the authoritative tenant model, the list of embedded dashboards and charts, the datasets behind them, and the schema owners who can confirm column meanings. You also need someone who owns the backend that issues guest tokens, because the token must carry only the resources and RLS clauses that the authenticated user is entitled to see. Access to a staging Superset with the same database connections and a non-production copy of representative data is needed to test without exposing real customer records. Finally, name a decision-maker for how long tokens live and how the host application refreshes them.
Can an internal team build guest token RLS without outside help?
Yes, an internal team with strong backend, Superset and database skills can build it alone, provided it has time to design and test the rules thoroughly. The work requires knowledge of Superset's guest token and RLS features, of your tenant data model and of how the embedding application authenticates users. The hardest part is usually not the configuration but proving that no customer can see another customer's rows across every dashboard, chart and export path. Teams without a dedicated security tester often find that gap. An independent test pass, either from an internal team separate from the builders or from an outside firm, closes it. DeployOpen can plan, build and test this work, or test a design your team has already built.
How does token lifetime change the effort and the risk?
Shorter token lifetimes reduce the window in which a leaked or misused token can expose data, but they increase the number of refresh requests your backend and the embedding page must handle. Longer lifetimes simplify the frontend but enlarge the exposure window. Choosing a lifetime is a security decision, not only an engineering one, so record the chosen value and the reasoning in the design. The effort added by lifetime changes is mostly in the refresh flow, error handling when a token expires mid-session and tests that confirm an expired token is rejected. Confirm the exact guest token settings for your Superset version in the configuration documentation before you finalize the design.
How does the number of tenants change the work?
The number of tenants changes the test matrix and the operational load more than the core rule design. A single RLS rule keyed to a tenant identifier can serve many tenants, but every additional tenant adds cases that testers must confirm, especially tenants with unusual data, shared users or mixed roles. Large tenant counts also make it important to automate leak tests, because manual checks do not scale. If you expect tenants to need different databases, schemas or instances, the work moves toward a different architecture, which is covered in the multi-tenant design topic. Ask any partner how the test suite grows with tenants and who maintains it.
What tests prove that tenants cannot see each other's data?
Leak testing should authenticate as one tenant's user, request tokens for that tenant, and attempt to read every dashboard, chart, dataset preview and export that the token exposes, then compare returned rows with the expected tenant. Tests should also try tampered tokens, tokens requested for another tenant's resource identifiers, and datasets added after the initial build. Run these tests in staging after every dashboard change, dataset change and Superset upgrade. Record results as evidence for your own assurance process. Note that DeployOpen prepares controls and evidence for compliance assessments, but independent auditors issue any audit report.
What recurs after the guest token RLS build is complete?
Recurring work includes rerunning leak tests after dataset or dashboard changes, reviewing RLS rules when schemas change, and testing each Superset upgrade in staging before production. Upgrades require a metadata database backup, running superset db upgrade and superset init, and checking UPDATING.md for breaking changes. Token service code also needs maintenance when your identity provider or tenant model changes. Budget for these as an ongoing operations cost, whether an internal team or a retainer covers them. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and quotes follow from a written scope.
What a fixed-scope RLS and embedding engagement covers
A fixed-scope engagement on guest tokens and row level security starts with a written scope that names the work, the deliverables and the acceptance checks. The first step is a data model review of the analytics databases behind each embedded dataset: which tables carry a tenant key, which joins can drop that key, and which datasets already expose data across customers. The review also records the Superset roles and dataset permissions that the embedded viewer role will hold, because RLS rules only restrict data that the role can already reach. Scope, deliverables and timelines are agreed in writing before this work begins, and a quote follows from that written scope.
The core design deliverable is the RLS rule set, documented per dataset with the clause, the roles it applies to and whether it is attached to a dataset or applied to all datasets. The engagement also reviews the backend token service that requests guest tokens from Superset: how it authenticates the host application user, how it maps that user to the resources and rls entries it sends, and how it sets the token expiry. Effort depends on the number of datasets, the complexity of the tenant model and whether the existing backend already handles authorization cleanly. Ask any firm to state which of these items are included, how many datasets and roles are in scope, and whether the backend review is a separate line item.
The leak test plan and handover close the engagement. The test plan defines cross-tenant requests to run against the embedded dashboards and the guest token endpoint, expected results for each, and the evidence to keep, so the client can rerun the tests after each release. Handover covers the rule documentation, the token service notes and the test scripts in the client's own repository. Ongoing work such as re-testing after Superset upgrades or new datasets is a recurring cost that should appear as a separate retainer or change request, not as an assumed part of the one-time fee. Confirm the Superset version you run, since the Apache Superset releases page lists the versions in use and their status.
How DeployOpen scopes, delivers and supports this work
DeployOpen starts with a written list of embedded dashboards, the data each viewer type may see, and the tenant boundary your application enforces. We then build and test the guest token flow and RLS rules inside your own infrastructure, and hand over documentation your team can run and audit. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Written scope lists each embedded dashboard, chart and dataset that guest tokens will expose.
- Scope records the tenant identifiers, RLS clauses and roles your backend must pass into each token.
- Quote follows from the written scope, so ask which token lifetimes and test cases are included.
How we build
- We configure guest token resources and RLS rules in your Superset instance, with rules tied to each dataset.
- Backend token issuance is built so that tenant identity comes from your authenticated session, not from the browser.
- Leak testing runs cross-tenant requests against every embedded dashboard before any customer sees it.
How we hand over
- Documentation maps each RLS rule to its dataset, tenant claim and the owner who approves changes.
- Test scripts for cross-tenant access are delivered so your team can rerun them after each change.
- Handover includes a walkthrough of token lifetime settings and the steps to rotate signing secrets.
How we support
- Retainers cover upgrades, including checks of UPDATING.md notes before each Superset version change.
- Ongoing testing repeats cross-tenant leak checks when new dashboards or datasets are added.
- Support requests are handled under the agreed retainer, with changes tracked against the written scope.
