Why a Superset production security checklist comes before go-live
A team about to give analysts access to Apache Superset and connect it to production warehouses should run a written security checklist before go-live, because the defaults that make Superset quick to try are not safe defaults for a shared system. Superset ships with a SQLite metadata database for Quickstart and PyPI installs, and the project's architecture documentation says SQLite is not recommended for production. Production needs PostgreSQL or MySQL as the metadata database, and the configuration documentation lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Confirm the exact versions against your target release before you build. Superset also requires a user-specified SECRET_KEY to start, so the key is a deployment decision you make, store and protect, not something you accept from a default.
Superset is licensed under the Apache License 2.0 and has no paid edition, so no vendor reviews the security posture of your instance or signs off on it. The work of hardening, testing and operating it belongs to your team or the partner you hire, and a gap that nobody owns tends to surface only after analysts have been running queries for months. The checklist should cover four areas: configuration (secret key, TLS at the proxy, security headers, SQL execution limits), identity (IdP login, disabling the default admin, mapping groups to roles), database privileges (read-only warehouse accounts and scoped datasets), and logging (who ran which query, exported what, and changed which role). Each item should have an owner and a pass or fail result recorded before the go-live date.
Start by reading the release you plan to deploy. The GitHub releases page and the project's upgrade notes show which version is current and what has changed, so confirm the version you pin against those sources and the UPDATING.md breaking change notes before you write the checklist. Many items below depend on settings that differ across versions, so a checklist written against one release can be wrong for the next. Assign one person to own the checklist, keep it in version control with the deployment code, and rerun it after every upgrade and every change to roles or database connections.
Which controls every production Superset needs before users sign in
These controls work as a set. Transport security, secret handling, session management, identity, privilege design, response headers, edge filtering and logging each close a different path into the platform. Skipping one usually leaves a gap that the others cannot cover.
TLS terminated at the proxy
Terminate HTTPS at a reverse proxy or load balancer in front of Superset so credentials and session cookies never cross the network in clear text. Confirm that the proxy forwards the original scheme and host, since Superset needs that information to build correct redirect and cookie behavior. Check that plain HTTP on the public interface is closed rather than redirected only for browsers. The proxy is also where certificate rotation is managed, so assign an owner for it before launch.
Unique SECRET_KEY per environment
Set a SECRET_KEY that is generated for each environment and never copied from a sample file or another instance. Superset requires a user-specified value to start, and that value signs session data and protects credentials stored in the metadata database. A key shared between staging and production lets tokens from one environment be used in the other. Store it in your secrets manager and confirm that the rotation procedure, including PREVIOUS_SECRET_KEY, is documented.
Server-side sessions
Configure a server-side session backend, such as Redis or the metadata database, so that logout and forced session termination act on the server and not only in the browser. With default cookie sessions, a copied cookie can remain usable until it expires. Set a session lifetime that matches your policy and review the cookie flags the backend applies. Test logout from two browsers to confirm the first session is actually invalidated.
IdP login through OAuth2 or LDAP
Route all user sign-in through your identity provider using OAuth2 or LDAP, and remove local password accounts for normal users. Superset is built on Flask-AppBuilder and can map provider groups to Superset roles with AUTH_ROLES_MAPPING, so access follows directory membership. Decide in advance who may create users, how deprovisioning removes role grants, and which group names map to which roles. Verify that a disabled account in the directory cannot sign in.
Least-privilege roles and database users
Give users the narrowest built-in or custom role that covers their work, and give Superset a read-only database account scoped to the schemas it needs. Role assignment controls what appears in the interface, but the warehouse account controls what the data can actually return, so both layers matter. Avoid granting Admin or broad Alpha rights to general analysts, and confirm that the connection account cannot write or drop objects. Record which accounts exist and who approved them.
Talisman security headers
Enable Talisman to set browser security headers, including Content Security Policy, HSTS and frame options, and tune the policy for the map tiles, fonts and embedding origins your dashboards need. Headers are a browser-side control, so they limit script injection and clickjacking effects but do not replace authorization inside Superset. Test each dashboard type after changing the policy, because an overly strict rule breaks charts silently. Keep the configuration under version control.
Disabled default admin and WAF
Remove or disable the default admin account created during installation, and create named administrator accounts tied to your identity provider before go-live. Place a web application firewall in front of Superset to filter common attack patterns and restrict administrative paths to approved networks. Confirm that the default credentials no longer work from any path, including the API. Treat the WAF as an added layer, since it cannot see authorization decisions made inside the application.
Centralized logging and audit
Send Superset application logs, proxy access logs and database audit logs to a central log platform that your security team monitors. Logs should record sign-ins, role changes, failed authorization attempts and the queries executed through SQL Lab, so that investigations do not depend on the Superset host. Confirm retention periods with your compliance owner and test that alerts fire for a deliberate failed sign-in before launch.
Configuration to verify by layer: application, identity, data and network
Superset refuses to start without a user-specified SECRET_KEY, which is the first setting to verify. The key signs session data and protects credentials that Superset stores, so a key shared between environments or copied from an example file lets one environment's sessions be forged in another. Confirm the key was generated for this deployment, stored in your secrets manager and injected at runtime rather than written into a config file in source control.
- Unique per environment: Confirm production, staging and test instances each use a different key.
- Stored outside the repository: Check that
superset_config.pyreads the key from an environment variable or secret mount. - Rotation path: Confirm
PREVIOUS_SECRET_KEYis set during any rotation window and that the re-encryption step has been rehearsed in staging. - Backup handling: Check that database backups and the key are stored separately so a restored database can still be decrypted under the expected key.
- Key ownership: Name the person or team who can rotate the key and who responds if it leaks.
Ask the team to show the key's source in the running container or pod, not just in the configuration file.
Session settings decide whether logout actually ends access and how long a stolen session stays useful. The configuration documentation describes the session and cookie options, but the values you need depend on your identity provider, proxy and whether users embed dashboards in other sites. Review each setting against your own policy rather than accepting the defaults.
- Session backend: Confirm whether sessions are stored server-side in Redis or the metadata database, so that logout invalidates the server copy.
- Lifetime: Check the session lifetime against your organization's idle and absolute timeout requirements.
- Cookie flags: Confirm the secure and HTTP-only flags are set for every deployment that runs behind TLS.
- SameSite setting: Record the SameSite value and the reason for it, especially if embedded dashboards need cookies in iframes.
- Test logout: Log in, copy the session cookie, log out, and confirm the copied cookie no longer works.
The session tab is complete only when a logout test has been run on the production build with the final proxy in front of it.
Superset is built on Flask-AppBuilder and can authenticate through OAuth2 providers, LDAP or other supported methods. For production, login should go through your identity provider so that disabling a person in the directory removes their Superset access. Confirm the authentication type in the configuration, then confirm how groups from the directory become Superset roles.
- Single login path: Confirm local database login is disabled or limited to a named break-glass account.
- Group mapping: Check the
AUTH_ROLES_MAPPINGentries against the directory groups that should grant each role, and confirm no broad group maps to Admin by accident. - Default admin: Confirm the default admin account created at installation is disabled or its password is rotated and stored in a vault.
- Role sync: Confirm whether roles are refreshed at each login, and test what happens when a user leaves a group.
- Account lifecycle: Confirm who removes accounts when people leave and how often access is reviewed.
Check the mapping with at least one user from each group, because a typo in a group name usually fails silently.
Superset does not decide what a database account can read. The warehouse account it uses sets the real ceiling, and dashboard permissions only narrow what Superset shows. Confirm each database connection uses a read-only account scoped to the schemas its datasets need, and that the network path from Superset to the database is restricted to the expected hosts and ports.
- Read-only accounts: Confirm each connection uses an account without write or DDL privileges unless a documented workload requires them.
- Schema scoping: Check that the account can see only the schemas and tables that are exposed in Superset.
- Separate connections: Confirm sensitive datasets use a separate connection and account from general analytics data.
- Metadata database: Confirm the metadata database runs on PostgreSQL or MySQL in a supported version, not on the SQLite default, and that its account is separate from the analytics connections.
- Egress rules: Confirm firewall or network policy allows only the required destinations from the Superset hosts and workers.
Test each connection with a query that should fail, such as a write or a read from an unlisted schema, to confirm the database enforces the limit.
TLS and HTTP headers are usually terminated or set at the reverse proxy or load balancer before traffic reaches Superset. Check that the application trusts the forwarded headers it should trust, that HTTPS is enforced end to end, and that the headers match what your dashboards and embedding need. Confirm the exact behavior in the configuration documentation for your Superset version rather than relying on memory of older releases.
- TLS at the proxy: Confirm certificates are valid, plain HTTP is redirected, and only current protocol versions are offered.
- Forwarded headers: Check that Superset is configured to trust forwarded protocol and host headers only from your proxy.
- Security headers: Confirm Talisman or equivalent header settings are enabled, and record the Content Security Policy, HSTS and frame options in use.
- Embedding exceptions: Note any frame or CSP allowances required for embedded dashboards, and limit them to known origins.
- Header test: Scan the production URL and confirm the headers in the browser match the configuration.
Capture the final header values in the change record so a later proxy update does not silently remove them.
Which hardening options fit which deployment pattern
This table compares the main hardening choices for a production Superset against the install pattern you run it on. Read each row as a decision: the trade-off is what you gain and what you take on, and the last column says when the option fits. Confirm platform-specific behavior against the version you deploy, since session, header and Helm guidance changes between releases.
| Hardening option | Trade-off | Fits best when |
|---|---|---|
| Cookie sessions | Simple to run, but logout does not necessarily end a session already issued to a browser | Short-lived internal pilots only, with a plan to move off cookie sessions before go-live |
| Server-side sessions (Redis or database backed) | Adds a backend to operate and back up, and needs a SameSite decision for iframe embedding | Production deployments where logout must invalidate sessions and you already run Redis or a database |
| Local database login | Passwords and account lifecycle sit in Superset, so you own offboarding and password policy | Small teams, or break-glass admin access alongside a primary identity provider |
| OAuth2 or LDAP login | Identity stays with your provider, but group-to-role mapping must be designed and tested | Most workforce rollouts where joiners, movers and leavers are already managed centrally |
| Talisman with a tuned policy | Strong browser-side controls, but the Content Security Policy needs testing for maps, fonts and embedding | You control the application origin and can test dashboards against each policy change |
| Headers set only at the proxy | Keeps policy in one place, but Superset responses may not carry every header you expect | Your reverse proxy team owns headers and you have verified each header on Superset responses |
| Docker Compose or single host | Fast to stand up, with a single failure domain and manual patching and backups | Evaluation or a small internal deployment with a documented upgrade and restore routine |
| PyPI install on virtual machines | Full control of Python dependencies and configuration files, with more host hardening to own | Teams with mature configuration management that version-control superset_config.py |
| Kubernetes with the Helm chart or the operator | Scales and restarts well, but the Helm chart is marked deprecated for new deployments and the operator is alpha | Platform teams who accept the lifecycle risk, and who confirm the current recommended path before choosing |
Pre-go-live sequence: from first login to signed-off access model
This sequence takes a Superset install from an empty metadata database to a staging environment where non-admin users have been tested against the access model you intend to run in production. Each step closes with a check the reviewer can repeat and record.
Provision a supported metadata database
The platform team creates a PostgreSQL or MySQL instance for Superset's metadata, not the SQLite default or the Docker Compose PostgreSQL container, which the architecture documentation does not recommend for production. Confirm the version falls within the supported range in the configuration documentation (PostgreSQL 10 to 17, MySQL 5.7 and 8.x). Done when the instance is reachable only from the Superset application and worker hosts, backups are scheduled, and the connection string is stored in your secrets manager rather than in a file that is checked into source control.
Generate and store a unique SECRET_KEY
The platform engineer generates a dedicated SECRET_KEY for this environment and writes it to your secrets store. Superset will not start without one, and the key must never be reused across development, staging and production, because a shared key allows session forgery between environments. Check that the key is injected at runtime, that it is absent from images and logs, and that the team records where the key is kept and who can read it. Test that a staging restart succeeds with the injected value.
Configure the reverse proxy with TLS
The network or platform team places Superset behind a reverse proxy that terminates TLS with a certificate from your internal or public CA, and restricts direct access to the application port. Set the forwarded headers so Superset sees the correct scheme and host. Done when the site loads only over HTTPS, plain HTTP redirects, and a direct request to the application port from outside the proxy fails. Record the proxy configuration in version control so the setting survives redeployment.
Connect the identity provider and test login
The identity team registers Superset with your OAuth2 provider or configures LDAP, following the authentication options in the Superset configuration documentation. Confirm the callback URL matches the proxy hostname exactly. Test sign-in with a named staff account and confirm that the local login form is either disabled or restricted to break-glass use. Done when a user authenticates through the IdP and the account appears in Superset with the expected identity attributes.
Map IdP groups to Superset roles
Using AUTH_ROLES_MAPPING, the Superset administrator maps each directory or OAuth group to the roles it needs, avoiding a default assignment of Admin or Alpha to every authenticated user. Keep the mapping in configuration so changes go through review. Done when a test account from each group receives only the roles its group grants, and a user outside all mapped groups receives no data access. Document the mapping as the baseline your access review will test against.
Create read-only database accounts
The data platform team creates the database users Superset will connect with, granting read access only to the schemas and tables approved for each dataset, and no write or DDL privileges. Separate connections are used where sensitivity levels differ. Confirm the grants by attempting a write with each account and verifying it fails. Also confirm the network path only allows the warehouse connection from the Superset workers. Done when each account's privileges match the written data access request and the negative tests fail as expected.
Disable or rename the default admin and enable headers and logging
The Superset administrator removes or renames the default admin account after confirming a named administrator can sign in, and records the change. Enable the security headers through Talisman and configure application and proxy logs to capture logins, failed authentications and query activity, sent to your central log platform. Done when the default account no longer authenticates, a browser response shows the expected headers, and a test login and a test query each produce a log entry in the central store.
Sign off access with non-admin users in staging
Before production, testers sign in as a representative non-admin user from each role group and attempt the actions their role should block: opening dashboards they should not see, running DML where it is disabled, exporting data without permission, and reaching SQL Lab if it is not granted. Review results against the documented role mapping and the database grants. Done when every expected denial is recorded, every expected allowance works, and the owner of the data signs off the access model in writing before go-live.
How SECRET_KEY reuse and cookie sessions enable session forgery
Session forgery becomes possible when the same SECRET_KEY is shared across environments or left at a default value. Superset signs its session cookies with this key, so anyone who knows it can construct a cookie that the application accepts as a valid, logged-in session. A key copied from a staging host, a template file or a configuration repository gives every holder of that copy the same ability in production. Before go-live, confirm that each environment has its own key generated with a cryptographically strong random source, that the value is injected from a secret store rather than committed to source control, and that no developer workstation or CI job holds a production copy. Superset requires a user-specified key to start, so the risk is usually a copied value rather than a missing one.
Rotation is the control that lets you replace a key without locking out every user at once. Superset supports PREVIOUS_SECRET_KEY for this purpose, so the old key can still be read while data encrypted with it is re-encrypted under the new one. Plan the rotation as a change with a named owner, a staging rehearsal and a documented response if the key is exposed, because a leaked key means the rotation must happen immediately rather than on the normal schedule. The procedure, the re-encrypt step and the incident response are covered in the rotation page of this group, so this checklist only needs you to confirm that a rotation path exists and has been tested once.
Cookie-based sessions add a second problem. When the session state lives entirely in the cookie, the server has no record to delete when a user logs out, so a copied cookie can remain valid until its signed expiry. Confirm which session backend your deployment uses and whether logout actually invalidates the session on the server. Moving to a server-side backend such as Redis or the metadata database is the usual fix, along with a defined session lifetime and cookie flags. Test it directly: log in, copy the session cookie, log out, then replay the cookie. The configuration details and the SameSite trade-off for embedding are covered in the server-side sessions page of this group.
Security risks that remain after the checklist is complete
A completed checklist removes known misconfigurations, but several risks stay open because they come from how people use Superset once it is live. The cards below cover access grants, SQL execution, exports, dashboards and patching, with a test for each.
Over-assigned Admin and Alpha roles
Admin and Alpha users can change data sources, edit other users' content and reach far more of the application than most analysts need. Each extra admin widens the blast radius of a stolen session or a mistaken click. Review who holds Admin and Alpha against the people who truly maintain the platform, and remove the rest. Test by logging in as a representative analyst account and attempting to edit a database connection, a role or another owner's dashboard. Re-run that test after every upgrade, because superset init resets edited built-in roles.
All-database access grants
The all_database_access permission lets a role query every connected database, which can expose warehouses that were never meant for that audience. It often gets granted during setup to clear access errors and then stays in place. Replace it with per-database or per-schema grants, and confirm that each custom role sees only the datasets it needs. Test by listing the databases and datasets visible to a sample account from each role, then compare the lists with the access matrix you signed off.
SQL Lab DML and disallowed function gaps
Turning off DML on a database blocks writes through SQL Lab, but disallowed function lists only cover what someone has already thought to add. Functions that read files, call external hosts or change session state can remain available on engines you did not expect. Confirm DML is off for each database that does not need it, review the DISALLOWED_SQL_FUNCTIONS list for your engine, and check that SQL Lab exposure matches your policy. Test with a read-only sample account by attempting an insert, a DDL statement and engine-specific functions, and record which queries reach the database.
Export of data users can already see
Export controls govern CSV, Excel and other downloads, but a user who can view a chart can usually reconstruct its data through screenshots, copy and paste or repeated queries. Restricting export reduces bulk extraction, but it does not stop disclosure by a user who is allowed to see the data. Decide which roles need downloads, log exports where your audit tooling allows, and state this limit in your data handling policy. Test by confirming that a role without export permission cannot download a table, and that a permitted role's downloads appear in your logs.
Unpatched releases in production
A correct configuration does not protect a deployment running a release with a known vulnerability. Superset is released under the Apache License 2.0 and has no paid edition, so patch timing depends entirely on your own process. Track the releases you run against the project's release list, separate application findings from container image findings, and plan upgrades with a tested backup. Test by confirming the running version in staging and production, then re-running your role and RLS checks after each upgrade.
Dashboards leaking through shared datasets
Dataset-based permissions let anyone with access to a dataset see every dashboard built on it, including dashboards owned by other teams or still in draft. A role that looks narrow can therefore reach sensitive charts indirectly. Use dashboard-level role access where separation matters, and review which owners publish to shared datasets. Test by logging in as a user with access to one dashboard only, then checking whether the dashboard list, search results and direct URLs expose any other dashboard built on the same datasets.
Questions teams ask before hardening Superset for production
What does hardening Superset for production cost?
The cost depends on the written scope, so there is no standard figure to quote here. Most of the fee pays for people: someone to review the current deployment, design roles and database accounts, configure TLS, sessions, headers and IdP login, and then test each control. The main drivers are how many databases and schemas Superset connects to, how many user populations need different access, whether single sign-on already exists, and how much of the work is documentation and evidence. Ask any partner for a fixed-scope quote that lists each control, the environments covered and the test steps. Ongoing patching and retesting recur, while the initial review is one-time.
How long does a pre-go-live Superset security review take?
Duration depends on the scope agreed in writing before work starts, so this page does not give a number. The factors that move it most are the number of data sources and roles to review, whether the identity provider and warehouse administrators are available quickly, whether Superset runs on containers, a virtual machine or Kubernetes, and how many fixes the review finds. A review that only confirms settings is shorter than one that also changes role design, rotates the secret key and retests permissions afterward. Ask for the timeline as milestones tied to access you need from your team.
What access and people does the hardening work need from our team?
The work needs named contacts and access before the first review session. Typically this includes an administrator for the Superset host and its reverse proxy, an owner for the metadata database, an identity provider administrator who can register Superset as an OAuth2 or LDAP client and share group membership, and warehouse administrators who can create read-only accounts and network rules. A business owner should confirm which datasets each user group may see. Ask the partner to list these access requests in the scope so you can schedule them before the work begins.
Can our internal team harden Superset without outside help?
Yes, a capable internal team can complete the checklist, and many do. The Superset configuration documentation covers the settings involved, including SECRET_KEY, session handling and AUTH_ROLES_MAPPING. The harder parts are usually role and database design, which requires understanding what each user population should see, and testing that permissions hold after each upgrade. Consider whether your team has time to test access paths, document decisions for auditors and repeat the work after patches. An outside review can add an independent check, but the decision belongs to your organization.
Does DeployOpen issue audit reports or certifications for our Superset deployment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. What DeployOpen can deliver is the configuration, role mapping, logging settings and documentation that an auditor will test, along with security testing results. Confirm with your assessor which evidence they expect before the review starts, because the format they accept determines how the deliverables should be written.
Which Superset settings do engineers check first before go-live?
Start with the items that change the trust boundary. Confirm TLS terminates at the proxy, that SECRET_KEY is unique per environment and was set before first start, and that the default admin account is disabled. Then check that sessions are server side so logout ends them, that login goes through your identity provider, and that Talisman sets the headers you intend. Finally, verify that each database connection uses a least-privilege account, that DML and risky SQL functions are restricted, and that logs reach your central system. Each item should have a test you can repeat after an upgrade.
Does the Superset license or project status affect hardening work?
Apache Superset is released under the Apache License 2.0 and has no paid edition, so hardening does not depend on a commercial license. The work is about configuring your deployment, not buying features. Track the release line you run, since release candidates such as 7.0.0rc2 are pre-releases and should not be the basis for a production baseline. Before you commit to a version, read the upgrade notes for that release and confirm which security fixes it includes.
How DeployOpen scopes and delivers a Superset security hardening engagement
DeployOpen plans, implements and documents Apache Superset production security controls inside your own infrastructure, from TLS and secret handling through role design and logging. The work follows a written scope agreed before any change is made, so each checklist item has a named owner, a test and an evidence record.
How we scope
- We review your planned Superset version, metadata database, proxy path, identity provider and warehouse connections before agreeing scope.
- The written scope lists each checklist control, the environments covered and the verification evidence you will receive.
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
How we build
- We configure TLS at the proxy, a unique SECRET_KEY, server-side sessions and Talisman headers in staging first.
- We map identity provider groups to Superset roles and build least-privilege database accounts for each data sensitivity level.
- We test each control against login, dataset access, SQL Lab limits and export permissions before promoting changes to production.
How we hand over
- You receive configuration records, role and database account inventories, and a list of tested controls with results.
- We document the upgrade path, including metadata database backups and the superset db upgrade and superset init steps.
- Operators receive runbooks for key rotation, disabling the default admin account and reviewing audit logs.
How we support
- Retainers cover patch upgrades, re-testing of roles and permissions after each Superset release, and header regression checks.
- We confirm which controls your compliance assessors will test, and prepare evidence without issuing any audit report.
- Before go-live, we agree with you which open items remain and who owns each one after handover.
