Apache Superset public roles need a data-scope inventory
A public dashboard can be a deliberate product feature or an accidental disclosure. The difference is often the dataset access granted to the role behind the dashboard. Apache Superset's security model supports public roles and guest tokens for embedded content. A review should ask what data those access paths can reach and how the organization will notice when that scope changes.
Public does not mean unrestricted
Superset documentation describes the Public role as a place to grant dataset access. For embedded content, a guest token scopes its holder to the dashboards named in the token and fails closed. The token can include dashboard access and can be narrowed further in some deployments. The role itself still needs a careful review because a public dashboard may touch more than one dataset.
A common mistake is to test only the dashboard page. The useful test checks the underlying data access. Can a public viewer see a field that should be restricted? Can a guest token reach a dataset that was not intended for embedding? Does row-level security apply to the same identity when the chart is viewed through an API rather than the browser?
A bounded ZoomEye observation
A count-only ZoomEye query was run on 2026-10-31. app="Apache Superset" returned 101992 matches. title="Superset" returned 101992 as well. Both used page 1, page size 1, and sub_type=all. The equal counts do not prove that the two queries identify exactly the same assets. They are separate observations that happened to return the same total in this scope.
The count is a discovery signal for deployments with a Superset fingerprint or title. It does not show whether public sharing is enabled, whether a public dashboard exists, or whether a matching deployment exposes sensitive data. Those questions require access to the deployment configuration and a controlled test with a known viewer role.
Inventory the public paths
List every public dashboard, the datasets and columns it uses, the role that grants access, and the team that owns the dashboard. Include embedded dashboards and their guest-token issuer. A dashboard may be marked public while its owner has since changed the dataset definition. Recheck the mapping after data-model changes, not only when the dashboard UI changes.
Separate the deployment's public role from its service account. The service account that signs guest tokens should not be a general-purpose administrator. Rotate its secrets according to the deployment's security guidance, and keep the signing secret out of frontend code. A publicly reachable dashboard should not be able to mint its own guest tokens.
Test what a viewer can reach
Open the dashboard as an unauthenticated viewer and as a guest token holder. Try a dataset that is not part of the approved dashboard, a field marked sensitive, and a chart navigation path. Capture the response, not just a screenshot. Check whether the denial is enforced at the data layer or only hidden by the interface.
Review dashboard ownership and sharing settings after staff changes. An owner who leaves the team may leave a public link active. A link can outlive the business decision that created it. Keep a review date and a removal path for each public link.
Use the observation responsibly
ZoomEye can help find a population of Superset instances that deserve an owner and configuration check. It cannot prove that a public dashboard is wrong. Pair the search with a local inventory of sharing state, dataset grants, guest-token use, and row-level security. That combination gives teams a defensible way to decide which public analytics surfaces should remain available.
Top comments (0)