Restricting data export and downloads in Apache Superset starts with knowing who can see the data
Granular export permissions let you assign export, image and clipboard rights per role, but they do not stop anyone who can view a dataset from reading it. A user who can open a chart, a table or a SQL Lab result can always read the values on screen, so the export controls decide how easily that data leaves Superset, not whether the user has seen it. Start by confirming which roles can reach each dashboard and dataset, because that access model sets the ceiling for everything the export controls do afterward.
Teams usually need this when a population must view dashboards for operational or executive reporting but should not pull raw rows into spreadsheets, screenshots or shared files. Examples include a regional manager who should see aggregated sales figures, or a contractor who needs a single dashboard and nothing more. The controls sit behind the GRANULAR_EXPORT_CONTROLS feature flag, so you must enable it deliberately in your configuration before any of the new permissions take effect. Confirm the flag's behavior in the Superset granular export controls documentation for the release you run, since flag behavior can change between versions.
Before you change roles, inventory who currently holds export rights and which datasets contain sensitive fields. Many existing roles received the older can_csv permission, and the migration to granular controls grants the new export, image and clipboard permissions to those roles, so an upgrade can widen access if you do not review the result. Plan to test with one account per population in staging, then decide which datasets need row-level or column-level restriction elsewhere, because export controls alone cannot hide data a user is already allowed to view.
Export permission options and when each fits
This table compares the three granular export permissions with the legacy model used when the GRANULAR_EXPORT_CONTROLS flag is off. Read each row for the output it governs, the teams it usually suits, and what it leaves open for users who can already see the data. The main takeaway is that no permission stops someone who can view a value from reading or retyping it.
| Option | What it governs | When it fits | What it does not block |
|---|---|---|---|
| can_export_data | Downloading query results from charts and datasets as files, such as CSV, Excel or JSON, per the granular export controls documentation | Analysts who need extracts for their own tools and analysis | Reading, selecting, retyping or screenshotting values the user can already see |
| can_export_image | Exporting charts or dashboards as images | Report distribution where a picture of the chart is enough | Screenshots, and the underlying values if the user also holds can_export_data |
| can_copy_clipboard | Copying chart or table content to the clipboard | Controlled sharing of results into documents or chat without creating a file | Manual selection and retyping, screenshots, and file exports for users with can_export_data |
| Flag off (legacy can_csv) | A single CSV export permission used before the granular model is enabled | Environments not yet migrated, or teams that need no change in behavior | Image and clipboard are not separately controlled. Confirm which export paths can_csv covers in your version. |
| Flag on, migrated roles | Roles that held can_csv receive all three granular permissions in the migration | A starting point before you tighten roles one permission at a time | Everything until you remove a permission from the role, so review each migrated role |
Setting up export controls without breaking existing roles
This sequence turns on granular export permissions in staging first, so each role's export rights are reviewed and tested before any change reaches production users. It also keeps a tested rollback point in place if a role loses access it still needs.
Confirm the Superset version and feature flag
The platform engineer or Superset administrator records the running Superset version and confirms that the GRANULAR_EXPORT_CONTROLS feature flag is available in that release before anything else changes. Check the release notes and the granular export controls documentation for your version, and confirm how your deployment sets feature flags in its configuration. The step is done when the version and the flag location are written into the change record and a staging instance reports the same version as production.
Back up the metadata database
The database administrator takes a full backup of the Superset metadata database, which holds roles, permissions and dashboard ownership, before any role or permission change. Follow the backup steps in the upgrade documentation and confirm the backup restores into a scratch database. The step is done when a restore test succeeds and the backup identifier is recorded in the change ticket, so the team can return to the pre-change permission state if needed.
Enable the flag in staging
The Superset administrator copies production configuration to staging, enables GRANULAR_EXPORT_CONTROLS there, and restarts the web and worker processes. Then they run the Superset database upgrade and initialization commands so the migration creates the three new export permissions and grants them to roles that previously held can_csv. The step is done when staging starts cleanly and the migration log shows no errors.
Review which roles hold the three permissions
The Superset administrator lists every role and its permissions in staging and checks which roles now hold can_export_data, can_export_image and can_copy_clipboard. Because the migration grants all three to every role that had can_csv, the review is where broad grants surface, including roles such as Alpha or custom roles that were never meant to export. Record a role-by-permission matrix and mark each cell as keep or remove. The step is done when every role has an explicit decision.
Remove grants from populations that should not export
Using the approved matrix, the Superset administrator removes the export or clipboard permissions from roles whose users should view data but not extract it, and leaves the grants in place only for roles with a documented business need. Make the edits in staging through the role management interface, and log who approved each removal. Note that a superset init run resets built-in roles to their defaults, so an edit to a built-in role can be overwritten. Keep custom roles and any edited built-in roles in a version-controlled export so they can be reapplied. The step is done when the matrix matches the staging role data.
Confirm edited roles survive initialization
Before promoting the change, the administrator runs the initialization command again in staging and reviews the role list to confirm that the intended edits persist. If built-in roles revert, the team restores them from its saved export and documents the reset in the runbook, so the next upgrade does not silently reopen export rights. The step is done when a second initialization run leaves the matrix unchanged.
Test each role with a real account
For every role in the matrix, the tester signs in to staging with a named test account that holds only that role and attempts a CSV export from a chart, an Excel or JSON export from a table, an image export from a dashboard, and a clipboard copy. Each attempt should succeed or fail exactly as the matrix states, and the tester records screenshots or response messages. Include a user who holds two roles to check how combined permissions behave. The step is done when every role has a signed-off test result.
Promote the change and keep the rollback point
After staging sign-off, the team applies the same flag setting and role changes to production in a scheduled window, repeats the backup, and runs the role spot-checks against production with test accounts. The rollback plan is the pre-change backup and the saved role export. The step is done when production role data matches the approved matrix and the change record links the test evidence.
What export controls prevent and what they leave open
Export permissions govern one action: pulling data out of a chart or dashboard through a defined export path. Users who can already see data have other ways to get it out, and some of those paths sit outside the export permissions entirely. Treat each card below as a control to test in your own environment, not as a guarantee.
Copying values from the table
A user who can view a chart or table can often select and copy the rendered values in the browser, and the clipboard permission only covers the copy-to-clipboard button. Check whether a role without can_copy_clipboard can still select cells and paste them into a file. Run the test with a Gamma-based test account that holds only the export permissions you intend to grant, and record what leaves the browser.
Screenshots bypass image controls
The export image permission stops the built-in image export, but it does not stop a screen capture, a browser print to PDF or a phone photo of the screen. Decide whether screen capture is an acceptable residual risk for each dashboard, and document that decision. For sensitive dashboards, test whether printing and PDF output are reachable from the browser menu for a restricted role.
SQL Lab and API results
SQL Lab returns query results through its own interface, and the REST API can return the same rows to any authenticated user with access to the endpoint. Export permissions on dashboards do not automatically cover these paths. List which roles can open SQL Lab, which databases they can query, and which API endpoints they can call, then confirm that each path is reviewed separately from chart exports.
Shared and public dashboards
A dashboard shared by link, published for anonymous access or embedded with a guest token can show data to people who hold no role grants at all. Those viewers may be able to download or copy what the dashboard displays, depending on how the dashboard and its embedding configuration are set up. Review every public or guest-accessible dashboard, confirm which datasets it draws on, and test what an unauthenticated visitor can export.
Dataset access still decides visibility
Export controls only act on data a user is already allowed to see. If a role can read a dataset, every export permission in that role applies to the full rows that dataset returns, and row-level security or column restrictions must be set on the dataset itself. Before relying on export permissions, confirm which datasets each role can query, which filters apply, and whether the exported rows reflect those filters.
Testing export restrictions for each role
Build a test matrix before you change anything: one axis lists each role in use (for example Gamma, Alpha, Admin and any custom roles you have created), the other lists each export path (CSV, Excel, JSON, image and clipboard copy) and each place it can be triggered (chart menu, dashboard menu, SQL Lab results, and the REST API). Each cell records the expected result, the actual result and the Superset version tested. Include a user who holds a dashboard role but not the dataset permission, and a user who holds the export permission but cannot see a given dataset, because those combinations are where restrictions most often fail. Under the granular model, verify the three permissions you are actually granting, can_export_data, can_export_image and can_copy_clipboard, rather than assuming that a role which once had can_csv still behaves as before. Confirm each permission against the granular export controls documentation and then in your own environment.
Run each cell with a real test account in a staging instance that mirrors production settings, including the feature flag state. Hidden buttons are not enough: a denied action should also fail when called directly against the API with that user's session or token, and the denial should appear in your audit trail. Record what the user sees when they try, because a clear permission error and a silent empty download are different findings. Keep test accounts in a separate group so they cannot be used for ordinary work, and remove them after each test cycle.
Re-run the full matrix after every Superset upgrade, after any change to role permissions, and after you enable or disable the feature flag. Upgrades can add permissions, rename them or change which roles receive them, so a passing result on one version does not carry forward. Check the release notes and UPDATING.md for the version you are moving to before the staging run, and treat any new permission in the matrix as untested until a cell covers it. Store the matrix with your change records so that the evidence of what was denied, when and on which version is available to whoever reviews your access controls next.
Export control questions teams ask before rollout
How long does it take to set up Superset export controls?
No single timeline fits every deployment, because the effort depends on how many roles hold export rights today and how many datasets and dashboards need testing. The work has three phases: inventorying roles and their current permissions, enabling the GRANULAR_EXPORT_CONTROLS feature flag and assigning the new permissions in staging, and testing each role against charts, dashboards and SQL Lab. Effort rises with the number of custom roles, the number of distinct export policies and the number of separate test accounts each role needs. Ask any provider to state the duration in the written scope, with the test matrix listed as a deliverable, so quotes cover the same work.
Can our own team set up granular export controls without a partner?
Yes, a team that already administers Superset can enable granular export controls alone, because the core change is a feature flag plus permission assignments. The steps are described in the granular export controls guide, which explains how the new permissions replace can_csv. The harder parts need judgment: deciding which populations may export which data, proving the result with test accounts and keeping the permission set intact through upgrades. Teams without a staging environment or a named owner for role design usually find testing and documentation take longer than the configuration itself.
What does a partner scope for export controls include?
DeployOpen works to a fixed scope, and the scope, deliverables and timeline are agreed in writing before work starts. For export controls, a typical written scope lists a review of the current role model, a permission map showing which roles receive can_export_data, can_export_image and can_copy_clipboard, configuration of the feature flag in staging and production, a test matrix run with one account per role and handover documentation for your administrators. Work outside export controls, such as dataset-level access design or warehouse account design, should appear as separate lines or be marked as excluded. Read the scope to confirm who performs the production change and who signs off the test results.
What must our team provide before export controls work begins?
The design depends on inputs that only your organization holds, so gather these before the work starts:
- A role inventory listing every built-in and custom role, its members and whether it currently holds
can_csv. - Data classification for each database and dataset behind your charts, stating which populations may export each class.
- Test accounts for each role, in a staging instance that matches production configuration.
- A named approver who signs off the export policy and the test results.
- Access to change windows and to the configuration path used for feature flags and environment variables.
Missing inputs are the most common reason an engagement waits, so confirm each item in the scope document before signing.
Do granular export controls satisfy audit requirements?
Export controls are a technical control that supports audit evidence, but they do not satisfy an audit on their own. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications, because independent auditors and certification bodies perform those. For an audit, you would typically show the role-to-permission map, the test results per role, the change record for the feature flag and the logs that show who holds export rights. Confirm with your auditor which control requirements they will test and whether they expect a periodic role review. Export controls limit downloads, but users who can view a chart can still read values on screen, take screenshots or transcribe figures by hand.
What happens to export roles when Superset is upgraded?
Export permissions survive an upgrade only if the upgrade process checks them, so treat the permission map as a tested artifact. The Superset upgrade guide asks you to back up the metadata database, run superset db upgrade and superset init, test in staging first and check UPDATING.md for breaking changes between versions. After each step, compare role permissions against your recorded export matrix and confirm the three granular permissions still map to the intended roles. Keep the matrix in version control so the comparison is repeatable, and record which release introduced each change. Ask whether post-upgrade permission checks sit inside a retainer or a one-time scope.
What drives the cost of export controls work?
Cost is the time of the people doing the work, so scope size and testing depth are the main drivers. Expect one-time costs for role inventory, design, configuration, testing and documentation, and recurring costs only where you buy ongoing work such as permission checks during upgrades or role changes after go-live. Costs rise with the number of custom roles, the number of databases at different sensitivity levels, the number of environments and the number of test accounts. They fall when your role inventory and data classification are complete before the engagement starts. DeployOpen does not publish a price list. Ask any provider for a quote with a line-item breakdown by phase, the assumptions behind each phase, the split between one-time and recurring items and which items are optional.
Limits to confirm in your environment
Granular export controls change which users can download data, but they sit on top of the dataset, dashboard and database access you already run. Each card below is a check to complete in your own Superset version before you rely on the controls for policy or audit evidence.
Confirm each permission's exact behavior
Test can_export_data, can_export_image and can_copy_clipboard separately in your release, using a test Gamma-based account for each. Confirm which UI actions and API calls each one gates, including CSV, Excel, JSON, image download and clipboard copy. Record the results, because a permission name alone does not tell you which export path it blocks.
Confirm the flag is available in your line
Check that GRANULAR_EXPORT_CONTROLS is supported and stable in the Superset version you plan to run, not only in the development branch. Review the release notes for the version you deploy and for any upcoming release candidate. Do not plan production policy around a feature that is still changing in your release line.
Test the flag with embedded dashboards
Embedded dashboards are often served to users who do not hold the same roles as internal analysts. Confirm which permissions apply to guest tokens and embedded sessions, and whether export actions appear there. Repeat the test for public dashboards. If the embedded or public path allows a download your policy forbids, restrict the dashboard or the dataset before go-live.
Check downstream export paths
Permissions in Superset do not stop a user who can see the data from querying it directly. Confirm whether SQL Lab, the API, scheduled reports and alerts, or a BI or spreadsheet client connected to the same warehouse account can still return the rows. Compare each route against the database account's read scope, since the warehouse account often has broader access than the dashboard.
Confirm which roles inherit export rights
Check every custom role, role mapping from your identity provider and existing role that carried can_csv before the migration. The migration grants all three new permissions to those roles, so audit each one and remove what does not match your policy. Verify the result after each superset init run, since role edits can be reset.
Confirm what remains visible on screen
Users who can view a chart can usually read its values, copy them with a browser, or take a screenshot, and blocking the export button does not stop that. Decide whether this residual exposure is acceptable for each data classification, and document it as a known limit. Review your data loss prevention and monitoring tools as the controls that cover it.
How DeployOpen scopes and delivers export controls
DeployOpen treats export restriction as a governed change to Superset roles, not a single switch. We start from which populations may download, which may only view, and which data must stay on screen, then build and test the permission model in your own infrastructure before handover.
How we scope
- Inventory which roles can export data, images or clipboard content today, including roles copied from can_csv.
- Agree in writing which export types each user population needs, and which datasets carry sensitive data.
- Confirm your Superset version and whether GRANULAR_EXPORT_CONTROLS is enabled before the work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- Map the existing can_csv grants to can_export_data, can_export_image and can_copy_clipboard, and document each change.
- Adjust custom roles so export permissions are separate from dataset and dashboard access, then test each role with real test accounts.
- Verify that export restrictions match what the UI, API and SQL Lab expose, since a permission check in one path may not cover another.
- Record the upgrade behavior of custom roles so later superset init runs do not silently reset the export model.
How we hand over
- Deliver a role-to-permission matrix showing which export actions each role holds, with the test results behind it.
- Document what the controls do not prevent, such as screenshots, copied values from visible tables and exports from users who can already query the data.
- Provide a runbook for granting or revoking export rights, including the review steps and the owner who approves changes.
- Hand over configuration as code where your deployment allows, so export settings can be reviewed like other changes.
How we support
- Retest export permissions after each Superset upgrade, following the project's upgrade guide and its breaking change notes.
- Review new dashboards and datasets for export exposure when they are published to wider audiences.
- Coordinate evidence collection with your internal or external auditors. DeployOpen prepares controls and records but does not issue attestations.
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing with your team.
