When public Superset dashboards make sense and when they do not
Anonymous access to a Superset dashboard works through the Public role. When AUTH_ROLE_PUBLIC is set, visitors who are not logged in receive that role, and the role grants only UI and API permissions. It does not grant data. A dashboard will render for an anonymous visitor only after you also grant the Public role access to the datasets behind its charts. Treat those two steps as separate decisions, because the role has no data access until you add it.
The central decision is what the Public role can query. Anything reachable by that role becomes readable by anyone who has the URL, with no login, no audit trail tied to a person and no way to revoke a single viewer short of changing the role or the URL. A public metrics page built on aggregated, already-published figures is a reasonable use. A partner view built on a dataset with customer rows, pricing or internal identifiers is not, even if the dashboard only shows totals, because the dataset itself is what the role can reach through the API.
Public dashboards make sense when the content is meant for everyone, is aggregated or non-sensitive, and changes rarely enough that you can review it before each release. They are a poor fit when the audience is a known set of partners, when rows are scoped per customer, or when you need to know who viewed what. For those cases, a logged-in role mapped from your identity provider or guest tokens for embedded viewers give you per-person control that the Public role cannot. Before you publish, confirm three things in your own environment: which datasets the Public role can reach, whether any virtual dataset or saved SQL could expose more columns than the chart displays, and whether a reviewer has signed off on that exact dataset list. Also confirm how your security team wants anonymous access logged and reviewed, since Superset's default logs will not identify the visitor. Your Superset version's security documentation is the place to verify the current role behavior.
How the Public role, dataset grants and login interact
When AUTH_ROLE_PUBLIC is set, anonymous visitors receive the Public role. That role grants UI and API permissions only, so the dashboard page loads and its layout, titles and chart frames appear. Dataset access is a separate permission, and without it the charts have nothing to query. The result is a dashboard that renders but shows no data, which can look like a broken deployment to the people who published it.
- Layout renders: the dashboard structure, tabs and markdown text are visible to anyone who reaches the URL.
- Charts stay empty: chart queries fail the permission check because the Public role has no access to the underlying datasets.
- Misleading symptom: publishers may read empty charts as a bug in the chart or database, when the cause is a missing grant.
- Partial exposure: text cells, titles and any values typed directly into markdown are still readable without login.
- Test with a private window: confirm this state in a browser session that is not logged in before assuming the grant is missing.
Before you go further, check that no markdown or description field contains figures you would not publish, because this configuration still exposes that content.
Granting the Public role access to a dataset makes its data available to anyone who can reach the dashboard, with no login required. The grant is the step that turns a rendered layout into a readable data product. Because the grant applies to the dataset, every dashboard and chart built on that dataset becomes readable to anonymous visitors, not only the one you intended to publish. This is the situation where the data exposure risk sits.
- Dataset scope: the grant covers the whole dataset, so columns and rows you did not chart can be reached through other charts or the explore view if the role has those permissions.
- Shared datasets: a dataset used by an internal dashboard and a public one becomes readable to anonymous users once granted.
- Rows and columns: row level security and column restrictions must be designed separately, and they should be verified against the anonymous session.
- Export and query paths: confirm what the Public role can download or query through the API, not only what the dashboard displays.
- Reversibility: removing the grant stops anonymous access, but any copies, exports or screenshots already taken stay outside your control.
Before granting access, ask the data owner to approve the exact dataset and the exact columns in scope, and retest from an anonymous session.
Enabling the Public role does not replace the roles that authenticated users already hold. A user who logs in receives their assigned roles, and the access they get comes from those roles, not from the anonymous configuration. This is the point most often misunderstood: a public dashboard should not change what an internal analyst can see, and an internal analyst should not be pushed to the anonymous view by accident. The two paths should be tested separately.
- Separate test accounts: check one logged-in user with a restricted role and one with broader access, then compare what each sees next to an anonymous session.
- Role inheritance: confirm which permissions a logged-in user keeps when the Public role also has access, since permissions are evaluated per role held.
- Login links: make sure the login page and any sign-in prompts behave as your team expects for visitors who arrive on a public dashboard.
- Publishing rights: the people who can change dashboards and grants should be a short, named group, separate from general viewers.
- Authentication scope: the public path bypasses login by design, so any data you do not want shared must stay behind a role without Public access.
Before release, ask your identity owner which authentication provider and role mapping apply, and check the result with the actual accounts you will use in production.
Configuration options for anonymous dashboard access
This table compares the Superset settings that decide whether anonymous visitors can reach a dashboard and what they can see. Read each row as a control you set, then confirm its exact behavior against the configuration documentation for your release. The main takeaway is that the Public role alone does not expose data, so each setting should be tied to a specific dataset and dashboard grant.
| Option or setting | What it does | When it fits | Main trade-off |
|---|---|---|---|
| AUTH_ROLE_PUBLIC | Sets the role given to anonymous users when no one is logged in, which is the Public role in the default configuration. | Dashboards must be viewable without a Superset login, such as a public statistics page. | Any anonymous request is served under this role, so every permission granted to it is open to the internet. |
| PUBLIC_ROLE_LIKE | Copies the permissions of an existing role, such as Gamma, onto the Public role. Confirm in your release whether it is applied at startup or through a sync step. | You want anonymous visitors to have the same UI and API access as a known role, then narrow it. | Copying a broad role such as Alpha or Admin grants far more than a read-only view, and the copy can drift from later role changes. |
| Public role UI and API permissions | Controls which menus, endpoints and actions anonymous users can call, such as viewing dashboards and charts. | Read-only viewing with no editing, exporting or SQL Lab access. | Some API permissions expose metadata or query results, so review each granted permission rather than relying on the role name. |
| Dataset permissions on the Public role | Grants access to specific datasets. Without these grants, a published dashboard loads but its charts show no data. | Each public dashboard should use only datasets that are approved for anonymous readers. | A dataset grant exposes all rows the dataset returns unless row level security is also applied, so a broad grant is a data leak. |
| Dashboard publication to the Public role | Makes a specific dashboard visible to anonymous users. Confirm in your release whether this is set in the dashboard UI or by assigning the dashboard to the role. | A small number of curated dashboards are meant for the public. | Publication is easy to do by mistake, and it does not show which underlying datasets the dashboard reads. |
| Row level security on public datasets | Filters rows per query for the roles that query a dataset, and can restrict anonymous access to a subset. | The public dataset contains some rows that should stay private. | Rules attach to roles and datasets, so each rule must be tested for anonymous requests before launch. |
| Guest token or login-based embedding | Lets a host application show a dashboard to its own viewers without making the dashboard public. | The audience is known and authenticated through your application. | This requires a backend that signs tokens and a separate review of the embedding settings. |
Setting up a public dashboard step by step
This sequence turns a private Superset instance into one that serves a single published dashboard to anonymous visitors, with backups, a deliberately narrow Public role and a logged-out check that confirms only the intended content loads. Each step ends with a check you can record before moving on.
Back up the metadata database and stage the change
Before touching authentication or permissions, take a backup of the Superset metadata database, since role, dataset and dashboard grants all live there. Make the change in a staging instance first, following the same backup and test-first approach the upgrade guidance recommends. Confirm the backup restores to a working copy in staging. The step is done when you have a tested restore point and a staging environment that mirrors production's database, datasets and dashboards closely enough to rehearse the change.
Confirm the secret key and session settings
Check that SECRET_KEY is set explicitly in superset_config.py or the environment, because Superset will not start without a user-specified value. Confirm that the value is unique to this deployment and stored in your secrets manager, not in the repository. If you are rotating an existing key, confirm PREVIOUS_SECRET_KEY is configured as the configuration documentation describes. The check is a restart of staging that succeeds with the key sourced from your secrets store, and a record of who can read that secret.
Enable the public role in configuration
In the staging configuration, set AUTH_ROLE_PUBLIC to the role anonymous visitors will receive, which is Public in the default setup. Decide whether PUBLIC_ROLE_LIKE is needed, and if so, note that it copies permissions from another role, so you should confirm exactly what that source role grants before using it. Restart staging and open the application in a logged-out session to confirm the anonymous session loads without a login prompt. Record the configuration diff so the change can be reviewed.
Grant the Public role only the access it needs
Open the Public role in the security settings and remove any UI or API permissions that a logged-out visitor does not need. Then grant dataset access one dataset at a time, limited to the datasets behind the published charts. Public role permissions alone do not show data, so the dataset grants are what make charts render, and they are also what makes over-broad access possible. The check is an export of the Public role's permission list that you review line by line, with every dataset grant traced to a chart on the target dashboard.
Review database and row-level exposure
Confirm the datasets granted to Public point to a database connection with the narrowest privileges that still run those charts, ideally a read-only account limited to the required schemas and tables. Check whether any dataset includes columns or rows that should not be visible to an anonymous audience, and address them with column choices in the dataset or with row level security rules before publishing. Ask the security owner to sign off on this exposure review. The step is complete when every granted dataset has a documented reason and a read-only database account is in place.
Publish the dashboard and record its state
Mark the target dashboard as published so it appears to anonymous visitors, and confirm that no other dashboards are published by accident. Set the dashboard's filters and default state to the version you intend to expose, since visitors will see whatever state is saved. If the dashboard will be framed on another site, note that iframe embedding has its own browser security settings to address in a separate review. The check is a list of published dashboards in staging that matches the approved list exactly.
Verify from a private session with no login
Open a private browser window with no Superset session, load the published dashboard URL, and confirm that only the intended charts render. Open each chart's query or data view if available, and try a few other dataset and dashboard URLs to confirm they are refused. Repeat the check after any change to permissions or datasets. The step is done when the logged-out test matches your approved list and a second reviewer has reproduced it, with the results saved to your change record. Promote the same configuration to production only after this passes.
Monitor the public surface after go-live
After production goes live, review which datasets and dashboards the Public role can reach each time a new chart or dataset is added, because grants are cumulative and easy to widen. Assign an owner to re-run the logged-out check after each Superset upgrade, since upgrade notes can change permissions and defaults. Keep the Public role's permission export in version control or your change log. The outcome is an ongoing record showing that the anonymous surface still matches the approved list.
Embedding public dashboards in iframes without exposing more data
A public dashboard placed in an external page is served by your Superset to any browser that loads the frame, so the host page gains a chart without gaining any access control of its own. The host page loses nothing it had before, but it inherits everything the Public role can already read. Framing does not add a second check. Whatever the Public role can query is what the iframe shows, and the host site's visitors, its scripts and its other embedded content all sit next to that data. Before you approve an embed, confirm which datasets the Public role can reach, which charts on the dashboard use them, and whether any filter or drill-through exposes rows that the static view hides.
Framing controls are a separate decision that the Public role review does not settle. Superset must allow its pages to be rendered inside another origin, and the Content Security Policy that governs that rendering controls which parent sites may frame it. A permissive frame-ancestors value lets any site embed the dashboard, while a missing or overly broad policy changes who can open the dashboard in a frame. Review the framing policy at the same time as the Public role, because loosening one to make an embed work can quietly widen exposure through the other. Confirm the exact policy in your deployment with your own configuration and the Superset security documentation, then test it from an origin that should be refused.
Plan the review as one change, not two. Record the parent origins allowed to frame the dashboard, the dashboard and dataset IDs, and the Public role permissions, and have someone who did not configure the embed test it from a page outside the allowed list. The detailed cookie, CSP and CORS settings for embedded Superset belong to the sibling topic on [browser security for embedded Superset]. Keep that topic open while you make the framing decision, since the cookie and CORS settings change what an embedded viewer can do after the page loads.
Data exposure risks of anonymous dashboards
Anonymous access removes the login step that normally limits who sees a dashboard and which rows they can reach. The cards below cover where that exposure comes from in Superset, from dataset grants and explore views to indexing, attribution and drift over time, and the control to apply to each.
Broad dataset grants
The Public role only receives dashboard and API permissions, so dashboards show data only after you grant dataset access to that role. A grant made for one chart often covers every table in the dataset's database or schema, which exposes columns the dashboard never displays. Scope each grant to the specific datasets the published dashboard uses, and review the role's permission list against the dashboard's dataset list before publishing.
Explore views exposing raw rows
A viewer who can open a chart in explore or export its results may see raw rows, column names and values that the dashboard was designed to summarize. Whether this is possible depends on the permissions and features granted to the Public role in your version, so confirm them directly. Limit the role to read-only dashboard access, and test as an anonymous browser session that every chart on the dashboard is the only path to its data.
Embedded dashboards found by crawlers
A public dashboard URL or an iframe on a public page can be discovered by search engines, link scanners and anyone who copies the address. Once indexed, the data stays reachable without any session. Decide which host pages may embed the dashboard, restrict framing in the browser policy, keep the dashboard out of search results where your page setup allows it, and check indexing after each publication.
No attribution for anonymous viewers
Anonymous requests carry no user identity, so audit logs can show that a dashboard was loaded but not who loaded it or from where. Investigating a suspected leak becomes slow, and an auditor testing access control will find no per-person evidence. Confirm which request, event and web server logs your deployment records for the Public role, and decide whether the dashboard's data is suitable for unattributed access at all.
Defaults and shared secrets left in place
Installs often keep sample data, example dashboards, default admin accounts or a placeholder SECRET_KEY from a quickstart. Any of these can expose data or let a visitor reach configuration meant for administrators. Before publishing, remove sample content, rotate the secret key, confirm no admin account uses a known password, and review the configuration file for settings copied from test environments.
Drift as datasets are added
The Public role can gain access to a new dataset whenever someone grants it for another chart, and no one may notice that the new data is now anonymously visible. This drift happens without any change to the dashboard itself. Keep a written list of datasets approved for the Public role, review it on a schedule and after every dataset change, and alert the owner when the role's grants change.
Questions teams ask before publishing a dashboard without login
Can I publish a Superset dashboard without login using only configuration?
Mostly yes. Anonymous users get the Public role when AUTH_ROLE_PUBLIC is set, and the role can be shaped through the Superset UI and configuration without custom code. The catch is that the Public role grants only UI and API permissions. Dataset access must be granted separately, or the dashboard loads with empty or error panels. Confirm the exact setting names and permission steps against the security documentation for the version you run, and test them in a staging instance before any data is exposed.
What makes a public dashboard take more effort to build?
The effort follows the data, not the chart count. The main drivers are:
- The number of datasets the dashboard touches, since each one needs an explicit grant to the Public role.
- Whether rows must be filtered per audience, which calls for row level security rules and careful testing.
- The review process, including who approves each dataset, the metric definitions and the text in charts.
- Whether the dashboard is also embedded in another site, which adds browser security settings.
Ask for the dataset inventory and review steps in writing before a quote is accepted.
What does our team need to provide for this work?
You need a named data owner for each dataset who can confirm what may be published, a security reviewer who signs off on the exposure before go-live, and a staging environment that mirrors production Superset settings and database connections. Your team should also decide which metrics are safe to show and which columns contain personal or commercial data. Without these inputs, the work stalls at review, regardless of how quickly the configuration is done.
Can our own team publish a public dashboard without outside help?
Yes, if your team already runs Superset and has someone who can administer roles, dataset permissions and the metadata database. The configuration itself is small. The risk sits in the review: deciding what anonymous visitors may see, checking that no sensitive column leaks through a chart, filter or export, and verifying the result from a logged-out browser. Many teams do the build internally and bring in an outside reviewer for the exposure check. A written scope makes that split clear.
How long does a public dashboard project take?
The duration depends on scope: how many datasets are involved, how many dashboards are published, whether row level filtering is needed, and how long your data owners and security reviewers take to respond. A single dashboard on one approved dataset is a much smaller piece of work than a set of dashboards across several databases. Ask for a timeline that lists each review gate and the staging test that comes before go-live. DeployOpen plans timelines in the written scope, so no duration is promised here.
What should we do if a dataset was exposed by mistake?
Act quickly and in this order. First, remove the Public role's access to the affected dataset and to any dashboard or chart built on it. Second, check the access logs and the Superset event records to see whether anonymous requests reached the data, and keep copies of that evidence. Third, review any embedded pages, cached results and exported files, since they may still show the data. Fourth, tell your data protection or incident response contact so they can decide on notification duties. Finally, add a review step so the same dataset cannot be granted again without sign-off.
Does a public dashboard need a separate security review before launch?
Yes. Treat any anonymous dashboard as a data release. The review should confirm the Public role's dataset grants, the charts and filters that could reveal individual records, the export and download options, and the browser headers when the dashboard is embedded. Confirm each control with the Superset security documentation for your version, then record the decisions so an auditor can trace who approved what.
Limits to confirm in your own environment
Public access sits on top of several Superset behaviors that vary by release and by how your identity provider and warehouse are configured. The cards below list what to confirm, and who in your organization should confirm it, before any dashboard is shared without login.
Public role behavior on your release
Confirm how AUTH_ROLE_PUBLIC and PUBLIC_ROLE_LIKE behave on the exact Superset version you run, not on the version in an older blog post or a previous project. Ask your platform team to test an anonymous session against a staging instance and record which menus, dashboards, charts and API endpoints it can reach. Keep that record with the release version so it can be repeated after each upgrade.
Row-level security for anonymous viewers
Confirm whether row-level security rules apply to the Public role in your setup and whether any rule is attached to it. A rule written for a logged-in group may not match an anonymous session, which can leave the dataset unfiltered. Have your security engineer create a test dataset with restricted rows, open the dashboard anonymously and check that only the intended rows appear.
Permalinks and thumbnails when anonymous
Confirm how dashboard permalinks and thumbnails behave for unauthenticated requests. Thumbnails and reports depend on the caching layer and Celery workers, and those components run under a service identity that may have broader data access than the anonymous viewer. Ask whether a permalink can be guessed or shared beyond the intended audience, and whether a thumbnail can expose data the dashboard itself hides.
Interaction with SSO and role mapping
Confirm how the Public role coexists with the Flask-AppBuilder role model once you enable OAuth2 or LDAP. Check that a user who signs in through the identity provider does not inherit Public permissions as a fallback, and that AUTH_ROLES_MAPPING never assigns a directory group a role broader than intended. Your identity team should own this check, and it should be repeated after any change to group mappings.
Per-viewer enforcement in the warehouse
Confirm whether your warehouse or query engine can enforce access per viewer. Superset connects with a service account, so anonymous requests usually run with that account's privileges. Ask your data platform owner whether that account can read only the datasets meant for public use, and whether query logs can identify the Superset request that ran each query.
How release notes treat Public role changes
Confirm whether each Superset release note and UPDATING.md entry flags changes to Public role defaults or permissions. Read them before every upgrade and rerun the anonymous access test in staging, since a default that changed silently can widen exposure. Ask the project's release notes owner, or your upgrade partner, to record each finding against the version it applies to.
A decision check before any dashboard goes public
Treat publishing a dashboard to the Public role as a release decision, not a configuration change. Before anyone sets AUTH_ROLE_PUBLIC or grants dataset access to the Public role, the review should answer one question: is every field this dashboard can show approved for release to anonymous visitors by the data owner? That approval should name the dashboard, its datasets, the time range and any filters, and it should come from the owner of the source data, not from the team that built the chart. If the owner cannot give that approval in writing, the answer is no-go, whatever the chart looks like.
Next, confirm that the Public role reaches only that approved data. The Public role grants UI and API permissions only, so the practical check is to list every dataset the role can read and compare that list with the approved scope. Look for datasets that were granted for a previous project, for SQL Lab access that could read beyond the dashboard, and for row level security rules that are missing or do not apply to the Public role. Then verify with a logged-in test account set to the same roles, and record the result. Ask your Superset administrator to confirm which login-free routes and embedded views are reachable, since a dashboard can be shared by link even when the rest of the instance is private.
Finally, record who approved the decision and when. The review record should hold the data owner's approval, the verification steps and their outputs, the name of the person who made the change, and a reviewer independent of the build. DeployOpen can prepare these controls and evidence for your compliance program, but independent auditors and certification bodies are the ones who assess them and issue any reports or attestations. Repeat the check whenever a dataset, a filter or the Public role's grants change.
Keeping public dashboards safe after launch
This sequence keeps anonymous access limited to the dashboards and datasets you chose at launch. It repeats the access check whenever Superset changes, data grows or the public role is touched, so exposure stays known and reversible.
Freeze the public role baseline
Record the Public role's current permissions, the datasets it can read, and the dashboards marked as published, and store the export with your change records. The owner of the Superset instance does this before go-live and after any change to the role. Done means you have a dated baseline that a later review can diff against, not a memory of what was granted.
Read UPDATING.md and test in staging
Before any upgrade, the platform owner reads the breaking change notes in UPDATING.md for every version between the current and target release, as the upgrade guide advises. The same upgrade is then run in a staging copy with a backup of the metadata database taken first, following the project's steps for db upgrade and init. Done means the staging instance has been checked for anonymous access to the public dashboards.
Review public role permissions after each upgrade
After each production upgrade, the security or platform engineer compares the Public role's permissions with the baseline and looks for newly added or changed grants. Upgrades can change default permissions, so this check is not optional even when the release notes look minor. Done means every difference is either explained and approved, or removed, and the review is signed off in the change record.
Re-test anonymous access when datasets change
Whenever a dataset is added to a published dashboard, or a chart is pointed at a new table, the owner opens the dashboard in a private browser session with no login and confirms what is visible. The tester also checks that the new dataset has not been granted to the Public role by accident. Done means the anonymous session shows only the intended charts and rows, and the test result is recorded.
Monitor usage and query activity
The operations team reviews query logs and usage data for the public dashboards on a schedule they set in the runbook, looking for unexpected query volume, slow queries against the warehouse, or access to datasets outside the intended list. Confirm which audit and event logging your Superset version provides and where it is stored before relying on it. Done means the reviewer has recorded the findings and opened a ticket for each anomaly.
Rehearse removing public access
Test the kill switch in staging: remove the public role's dashboard and dataset grants, confirm that an anonymous request is refused, and confirm that the dashboard still works for logged-in users. Keep the steps in a runbook so they can be run under pressure. Done means the rehearsal has a timed record, the steps are written down, and the named owner can perform them without help.
Repeat the review on a fixed cycle
The security owner sets a recurring review of the public role, the published dashboard list and the dataset grants, using the baseline from the first step as the reference. Each review checks for drift since the last one and for dashboards that are no longer needed. Done means the review record names the reviewer, the date, and any grants removed or approved, and the next review is scheduled.
How DeployOpen scopes public Superset access
DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Superset inside your own infrastructure. For public dashboards, we start by agreeing exactly which dashboards, datasets and roles may be visible without login, then build and test only that boundary.
How we scope
- Inventory every dashboard and chart you want visible without login, and record the datasets behind each one
- Document which data fields are acceptable for anonymous viewers and which must stay behind authentication
- Agree in writing whether the engagement covers iframe embedding, branding and the browser settings it depends on
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts
How we build
- Configure AUTH_ROLE_PUBLIC and PUBLIC_ROLE_LIKE only after the role's dataset grants are mapped and reviewed
- Grant the Public role dataset access one dataset at a time, then confirm each dashboard renders the intended data
- Test anonymous sessions against restricted datasets, direct API calls and export paths to confirm nothing extra is reachable
- Review the frame and browser settings that determine where a public dashboard can be embedded
How we hand over
- Deliver a written permission map listing each anonymous role grant, dataset and dashboard
- Provide test cases that repeat the anonymous access checks after every configuration or upgrade change
- Document how to add or remove a public dashboard, including the review step that should precede it
- Walk your team through the configuration so changes to public access are made deliberately
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so public access is rechecked after each Superset release
- Retainer work can include re-running anonymous access tests when new datasets or dashboards are published
- Ask any quote to name who maintains the permission map and who approves a new public dashboard
- Confirm with your security and compliance leads which findings from anonymous access tests they need documented
