Why Apache Superset penetration testing matters before go-live
A security assessment of Apache Superset is worth commissioning before go-live whenever analysts will log in to it and it holds credentials or read access to your warehouses. Superset is Apache-2.0 licensed with no paid edition, so nobody sells you a hardened hosted copy: the assessment examines your deployment, with your configuration, roles, database connections and identity provider. Because a Superset user's reach is defined by roles, dataset permissions, row level security and the database account behind each connection, a flaw in any one of them can expose data that the dashboard layer never displayed to that user.
A useful scope covers authentication and session handling, including whether logout ends the session and how the SECRET_KEY is stored and rotated. It tests role and row level security bypass attempts from a Gamma-style analyst account, Jinja and SQL injection paths in charts, virtual datasets and SQL Lab, and guest token handling if you embed dashboards. It also checks exposed API endpoints, export permissions, and whether the default admin account is still active. Ask the tester to name which of these they will attempt, which accounts they will use, and whether they will test against a staging copy that mirrors your database grants. Confirm the warehouse accounts in advance so a finding is not confused with a misconfigured test user.
Commission a fresh assessment in three situations: before the first analyst or customer login, after a major version upgrade, and before any embedded deployment. Upgrades change permissions and the security surface, so the upgrade guide's advice to test in staging first should include the security tests above, not only dashboard rendering. Embedding is the highest-risk moment because end users of your product, not your staff, become the people who can reach the data. Retesting after fixes is part of the same engagement, and the findings should map to specific settings, roles or database accounts that your team can change and verify.
Which test areas belong in a Superset assessment
A Superset assessment usually covers six areas that share one surface: the web application, the metadata database and the warehouse credentials behind it. Each area answers a different question about who can reach data, and the evidence should show what the tester did, what came back and what the fix should be.
Authentication and session handling
This area asks whether an unauthenticated or expired user can reach dashboards, charts or SQL Lab, and whether logout actually ends the session. Testers check login flows for each identity provider in use, session cookie attributes, token reuse after logout, and behavior when the SECRET_KEY is known or shared across environments. Evidence should include captured requests, cookie flags and a before and after logout test.
Role and permission bypass
This area asks whether a user can perform actions their role should block, such as editing dashboards, opening SQL Lab, exporting data or reaching datasets outside their grant. Testers compare what the UI hides with what the API accepts, and they repeat the checks with each built-in and custom role. Evidence should map each role to the requests it was allowed and denied, with the response codes recorded.
Row level security bypass
This area asks whether row filters hold when a user queries through charts, SQL Lab, saved queries, dataset previews or embedded views. Testers try filter clauses that are removed, reordered or commented out, check whether filters apply to every dataset that exposes the same table, and confirm that group-based filters match the group membership the identity provider sends. Evidence should show the same user receiving different row counts across each access path.
Jinja and SQL injection paths
This area asks whether user-controlled input can change the SQL that Superset sends to the warehouse, through Jinja templates in datasets, chart filters, SQL Lab parameters or dashboard native filters. Testers review where templating is enabled, attempt to inject statements or functions the database role should not run, and check whether DML is blocked per database. Evidence should include the exact query text observed in the database logs for each attempt.
Guest token handling for embedding
This area asks whether a guest token limits a viewer to the dashboard, filters and tenant data it was issued for, and whether a token can be reused, extended or forged. Testers decode token claims, replay tokens after expiry, change resource identifiers and test cross-tenant requests. Evidence should show each rejected manipulation with its response and the signing and expiry settings the issuing service uses.
Exposed API endpoints
This area asks which REST and internal endpoints answer without the expected authorization, and which ones return more fields or rows than the UI shows. Testers enumerate endpoints from the application, compare anonymous and low-privilege responses, check public dashboards and CSRF handling on state-changing calls, and review error messages for stack traces. Evidence should be a list of endpoints tested, the role used for each and any response that exceeded the intended scope.
Black-box, authenticated and embedded test scopes
This scope treats Superset as a black box exposed to the internet or to a partner network. The tester starts with only the hostname and whatever the reverse proxy, load balancer or WAF passes through. It reveals what a stranger can discover: login pages, version banners, health endpoints, static assets, public dashboards if the feature is enabled, and any API routes that answer without a session. It also shows whether TLS, proxy rules and access restrictions match the design. The tester usually needs only network reachability from the test source addresses and an agreed testing window. The customer should provide the public hostnames and IP ranges in scope, the proxy and WAF configuration, a list of any public dashboards or embedded routes, and written confirmation of which environments may be touched.
- Exposed endpoints: Map which application and API paths respond without authentication and compare them with the intended list.
- Public dashboards: Check whether any dashboard is published to anonymous visitors and what datasets sit behind it.
- Version disclosure: Look for banners or build metadata that reveal the Superset release, so patch status can be checked later.
- Transport and proxy controls: Confirm TLS settings, host header handling and whether internal paths can be reached through the proxy.
Before testing, confirm which of these results are in scope for remediation and which stop at the perimeter.
This scope gives the tester ordinary user accounts at the privilege levels the customer actually assigns, most often a Gamma-level user and an analyst who can use SQL Lab. It reveals whether role boundaries, dataset permissions and row level security hold when a user tries to step outside them. Testers check whether a Gamma user can reach dashboards, charts or datasets they were not granted, whether SQL Lab exposes databases the role should not reach, whether export controls can be bypassed through the API, and whether sessions end properly on logout. Testing should use at least two accounts per role so that cross-user access can be checked directly. The customer should provide test accounts with documented role membership, the dataset and dashboard inventory with the intended owner of each, the RLS rules in plain language, and the list of databases each role is meant to reach.
- Horizontal access: Confirm one user cannot read another user's saved queries, charts or dashboards by changing identifiers.
- Vertical access: Attempt admin or alpha actions from a Gamma account, including through direct API calls.
- Row level security: Test whether filters apply to every chart, query and export path that touches the protected table.
- SQL Lab exposure: Check which databases appear, whether DML is allowed and which functions run.
- Session behavior: Verify that logout and password change invalidate existing sessions.
Before testing, agree on whether the tester may run data-changing statements in a non-production database, since that changes the risk and the cleanup plan.
This scope covers Superset embedded inside another product, where the host application requests guest tokens on behalf of its own users. The tester needs both the Superset side and the host application, because most failures sit at the boundary: a host that issues tokens with broader resources than the user should see, tokens that are not bound to a tenant, or a host endpoint that signs tokens for any request it receives. It reveals whether the guest token scope limits access to the intended dashboard, whether RLS clauses in the token are enforced, whether a token can be reused across tenants, and whether the iframe and CORS settings allow framing from unexpected origins. The customer should provide the host application source or a test build, the token issuance logic and its authorization checks, the embedding configuration, a list of tenant identifiers for isolation tests, and a pair of test tenants with separate data.
- Token scope: Check whether the resources and RLS rules in a token can be altered by the client or widened by replaying a token.
- Tenant isolation: Attempt to read one tenant's dashboard with a token issued for another tenant.
- Issuance endpoint: Test whether the host's token service enforces the caller's own permissions before signing.
- Framing and origin controls: Confirm which origins may embed the dashboard and how headers apply to the embedding page.
Before testing, confirm who owns the host application's code so that findings in it can be fixed by the right team.
Test scope options and when each fits
This table compares five assessment options, the decision each one supports, and what your team must provide before work starts. Read it by first choosing the question you need answered, then checking the inputs your team can supply, because a narrow authenticated test rarely answers questions about embedding or exposed APIs.
| Option | Decision it supports | What you provide |
|---|---|---|
| Scoping workshop only | Whether a formal test is worth commissioning and which surfaces matter most | Architecture overview, deployed Superset version, auth method, list of connected databases and embedding plans |
| Targeted authenticated test | Whether role, dataset and RLS controls hold for specific user populations | Test accounts for each role, the role and RLS design documents, and a list of databases in scope |
| Full application and API test | Whether the internet-facing or internal Superset deployment can be compromised end to end | Staging instance matching production, network reachability rules, API endpoint inventory and written rules of engagement |
| Embedding test | Whether guest tokens, embedded dashboards and iframe settings isolate tenants correctly | Embedding application source or integration details, sample guest token claims, tenant mapping logic and allowed origins |
| Retest after remediation | Whether fixes from an earlier finding are effective and no new exposure was introduced | The original findings report, change records for each fix and access to the same environment used in the first test |
How a Superset security assessment is run
The sequence moves from agreed rules and scope to a staging instance that mirrors production, then to role-based testing and verified findings, so the client receives results they can reproduce and fix.
Confirm rules of engagement and written scope
The client and the testing team agree in writing on targets, permitted techniques, testing windows, data handling rules, and who to contact if something breaks. The scope names which Superset features are in play, such as SQL Lab, embedding with guest tokens, the REST API, and any exposed public dashboards. Testing starts only after both parties sign off. The step is complete when the signed scope document lists every in-scope URL, account type, and database connection.
Provide a staging instance that matches production
The client provisions a staging Superset with the same version, configuration, and reverse proxy as production. The SECRET_KEY must be set to a unique value, and the metadata database must be PostgreSQL or MySQL, not the SQLite default, because findings from a SQLite install may not reflect production behavior. Confirm the supported metadata database versions against the configuration documentation before you start. The step is complete when the team confirms the version, the configuration file, and the database engine in writing.
Create test accounts for each role
The client creates one test account per role the production model uses, including built-in roles and any custom roles, and per identity provider group if SSO is in use. Testers also need an account with no role to confirm that access fails closed. The testing team records the expected permissions for each account before testing starts, so that any deviation is measurable. The step is complete when the account inventory and expected access matrix are reviewed and approved.
Load representative datasets with RLS rules
The client loads datasets that resemble production in structure and sensitivity, with row level security rules applied to the tables that hold restricted data. Synthetic or masked data is preferred where real records are not needed for testing. The team checks that each RLS rule filters the rows it should, using the test accounts. The step is complete when a dry run shows expected rows for each account and the RLS configuration is documented.
Run tests against authentication, roles and injection paths
Testers attempt login and session abuse, privilege escalation between roles, RLS bypass through chart and SQL Lab queries, Jinja template and SQL injection paths, guest token misuse for embedded content, and access to API endpoints that the UI does not expose. Each test case records the request, the expected result, and the observed result. The step is complete when every planned test case has a recorded outcome, including tests that were blocked or not applicable.
Validate findings before reporting
Each candidate finding is reproduced by a second tester from the recorded steps, then checked against the configuration to rule out a test-environment artifact. The team assigns severity based on the data exposed and the access required, and notes any compensating controls the client already has. Findings that cannot be reproduced are dropped or marked as unconfirmed. The step is complete when each finding has a reproduction, an impact statement, and a remediation recommendation that the client can act on.
Retest after remediation
After the client applies fixes, the testing team repeats the original reproduction steps on the same staging instance and then checks adjacent paths the fix could have affected. For upgrades or configuration changes, the team also confirms that role permissions and RLS rules still behave as recorded in the baseline. The step is complete when each finding is marked closed with evidence, or reopened with a note on what remains.
Risks a test must not create in production
A penetration test of Superset is itself a source of risk: it can corrupt data, load warehouses, expose credentials and leave behind accounts or tokens. The cards below cover the controls that keep the test useful without turning it into an incident.
Test against a staging copy
Run active tests against a staging Superset that mirrors production configuration, including the same roles, RLS rules, SECRET_KEY handling, headers and proxy layer. Testing live production means a successful exploit can change dashboards, metadata or user records that real people depend on. Confirm with the client that staging matches production closely enough for the findings to carry over, and document every difference so the report can say which results need a production check.
Block destructive SQL exposure
SQL Lab and chart builders can send DML and DDL to any connection that allows it. Before testing, confirm with the owner which databases have DML enabled and use read-only test accounts. Injection tests should use read-only probes such as harmless SELECT expressions and timing checks, never statements that write, drop or alter tables. Record which connections were in scope so any unexpected write can be traced back to a specific test step.
Coordinate query load with warehouse owners
Fuzzing Jinja templates, RLS predicates and SQL payloads can generate many queries, long scans and repeated failures against a shared warehouse. Agree on a test window, request rate limits and a named contact who can kill sessions. Ask the owner whether the test account's query timeouts and concurrency limits are set, and whether anything in the warehouse alerts on unusual query patterns, so the test does not trigger a live incident response.
Protect test data and accounts
Testing requires accounts at several privilege levels, and those accounts often hold real database credentials. Use synthetic data in staging, create named test users with defined roles and remove them after the engagement. Store test credentials in the client's secret manager or an encrypted vault, limit who on the test team can read them, and confirm in writing when they are rotated or deleted. Keep captured sessions, tokens and exported files on encrypted storage with a retention limit.
Handle exposed secret material
A test may reveal the SECRET_KEY, database URIs, OAuth client secrets or guest token signing keys, for example through a debug page, a misconfigured file path or a verbose error. Stop testing that path, do not use the secret beyond proving exposure, and notify the client's security contact immediately under the agreed escalation terms. Ask the client to treat the secret as compromised and follow its rotation plan, including whether existing sessions and embedded tokens must be invalidated.
Confirm rules of engagement in writing
Scope, prohibited actions, testing windows, source IP ranges and emergency contacts should be agreed in writing before any traffic is sent. Name the systems that are out of bounds, such as the metadata database and production connections, and state how findings that touch them will be reported. Ask the provider how it documents each action taken, so the client can match test traffic in its logs to planned activity.
Questions buyers ask before commissioning a Superset security test
What drives the cost of a Superset security test?
The main drivers are the scope agreed in writing, how many roles and data access paths need testing, whether embedded dashboards and guest tokens are in scope, and how many environments are covered. Each added role model, database connection, embedding surface or environment adds test planning, test time and retest work. Ask any provider for a quote that lists these items separately, state which environments are tested (staging, production or both), and confirm whether a retest round is included. The quote follows from the written scope, and DeployOpen does not publish a price list.
How long does preparation take, and what must we supply?
Preparation time depends on how quickly your team can provide access and documentation, so the schedule is set during scoping rather than assumed. Before testing starts, expect to supply a non-production instance that matches production as closely as practical, test accounts for each role, a list of databases and datasets Superset connects to, the authentication configuration, and a description of any embedding flows. Confirm with the provider which of these they need, who signs off on test windows, and what rules apply to load and to testing against live warehouses.
Can our internal security team run this test themselves?
Yes, an internal team can test Superset, and many do. The trade-off is independence and coverage: a team that built or runs the deployment often shares its assumptions about role design and row level security. Internal staff need current knowledge of Superset's permission model, its SQL execution paths and its guest token handling, plus written authorization and a rules-of-engagement document. Many organizations use a mix, with internal teams running routine checks and an external test covering authentication, role bypass and embedding in a defined scope.
Will a penetration test satisfy our auditors?
A penetration test on its own does not satisfy an auditor. Independent auditors and certification bodies issue audit reports, attestations and certifications, and DeployOpen does not issue them. DeployOpen can prepare the systems, controls and evidence that an assessment will examine, such as role definitions, access reviews, test results and remediation records, and the findings can feed into that evidence. Ask your auditor early which controls they expect to test and which evidence format they accept.
How are findings retested after remediation?
Each finding should be recorded with its reproduction steps, affected component, severity reasoning and a proposed fix, so your team can apply the change and the tester can repeat the exact steps. Retesting usually happens after your team marks a finding as fixed, on the same environment and with the same test accounts. Agree in the statement of work whether retesting is included, how many rounds apply, and what happens to findings that you accept as a risk rather than fix. Confirm whether the retest result will be written up in the same report format.
When should we repeat the test after a Superset upgrade?
Repeat targeted testing after any upgrade that changes authentication, roles, permissions, SQL Lab behavior, embedding or the security configuration, and after any change to the secret key or session settings. The Superset upgrade documentation says to check UPDATING.md for breaking changes between versions, and permission behavior is a common area where changes need checking. A full repeat is worth scheduling after major version changes. Agree with your provider which upgrades trigger a scoped retest and which are covered by your own regression checks.
Which parts of Superset are most likely to need specialist testing?
Testing usually concentrates on the areas where configuration and code interact:
- Authentication and session handling, including logout behavior and cookie settings
- Role and row level security checks, including whether one role can reach datasets it should not
- Jinja templating and SQL paths that accept user-influenced input
- Guest token handling for embedded dashboards
- Exposed API endpoints and their permission checks
Each area needs test accounts for the relevant roles, so ask the provider to list the roles and data sets they expect to use.
How DeployOpen scopes and delivers Superset security testing
DeployOpen plans and runs security testing of Apache Superset inside the client's own infrastructure, from written scope through test execution to documented findings. Testing covers the application, its authentication and authorization paths, and the surrounding deployment, and it is delivered as a fixed-scope engagement with an optional retainer for continuing work.
How we scope
- Written scope names the Superset version, deployment model, metadata database and environments in test.
- Scope lists which roles, datasets, guest token flows and API endpoints are in and out of bounds.
- Agreed rules of engagement set test accounts, timing, data handling and who receives findings.
How we test
- Testing runs against staging or an agreed environment that mirrors production configuration.
- Test cases cover login, session handling, role and row level security bypass attempts, and SQL and Jinja injection paths.
- Embedding guest tokens and exposed API endpoints are tested with the same access model users hold.
How we hand over
- Deliverables include a written report with reproduced findings, affected components and severity reasoning.
- Each finding comes with remediation steps that your team or DeployOpen can apply and retest.
- A walkthrough with engineering and security staff covers results, open questions and retest criteria.
How we support
- Retesting after fixes confirms that each remediated finding is closed in the agreed environment.
- Ongoing support and continuous testing are available as a retainer under a separate written scope.
- Confirm with DeployOpen how retests, scope changes and new Superset releases are priced before signing.
