Apache Superset Hardening: 15 Security Measures

15 concrete measures to secure Apache Superset in production: SSO, RLS, CSP, secrets, audit. Complete 2026 guide.

9 May 2026 · Tuvalu Tech OÜ

Apache Superset is designed for flexibility, not security by default. Put into production without hardening, it exposes a significant attack surface: open SQL Lab, plaintext secrets, unencrypted sessions. This article lists 15 hardening measures to apply systematically, with their exact commands and measurable impact on security posture.

1. Why Superset requires explicit hardening

Apache Superset is a Flask application and inherits the strengths and weaknesses of that ecosystem. The default configuration favors easy startup: admin/admin account, demo SECRET_KEY, unsecured cookies, no CSP. All fine in test. In production, every parameter must be reviewed.

If you want to avoid this friction, TVL Managed Superset applies these 15 measures by default on every instance.

2. Authentication (measures 1 to 4)

Measure 1 — Mandatory SSO

Enable OIDC or SAML to centralize authentication. Local accounts should only persist for break-glass admin. OIDC sample:

from flask_appbuilder.security.manager import AUTH_OAUTH

AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
    {
        "name": "keycloak",
        "icon": "fa-key",
        "token_key": "access_token",
        "remote_app": {
            "client_id": "superset",
            "client_secret": os.environ["KEYCLOAK_SECRET"],
            "server_metadata_url": "https://idp.example.com/.well-known/openid-configuration",
            "client_kwargs": {"scope": "openid email profile"},
        },
    }
]

Measure 2 — Strong local admin password

If you keep a local break-glass account, its password must be 20+ characters, randomly generated, stored in a vault. Disable the default account with superset fab reset-password.

Measure 3 — MFA on the IdP

The IdP managing your SSO must enforce MFA for any Superset access. Responsibility lies with the IdP, not Superset. Also check OAuth tokens have reasonable lifetime (1h, refresh 8h max).

Measure 4 — Disable open registration

AUTH_USER_REGISTRATION = False
AUTH_USER_REGISTRATION_ROLE = "Public"

Without these lines, anyone can create an account if the URL is reachable.

3. Sessions and cookies (measures 5 to 7)

Measure 5 — Secure cookies

SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_SAMESITE = "Lax"
PERMANENT_SESSION_LIFETIME = timedelta(hours=8)

Measure 6 — CSRF protection

WTF_CSRF_ENABLED = True
WTF_CSRF_TIME_LIMIT = None
WTF_CSRF_EXEMPT_LIST = []

Check the exemption list: by default, some API routes can be exempted. Audit and harden.

Measure 7 — Strong SECRET_KEY

export SUPERSET_SECRET_KEY=$(openssl rand -base64 64)

Key must be 42+ characters. Store in a Kubernetes secret or Vault, never in Git. Rotation every 12 months recommended (forces all users to reconnect).

4. Network and transport (measures 8 to 10)

Measure 8 — Strict HTTPS with HSTS

ingress-nginx config:

nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/hsts: "true"
nginx.ingress.kubernetes.io/hsts-max-age: "63072000"
nginx.ingress.kubernetes.io/hsts-include-subdomains: "true"

Measure 9 — Content Security Policy

TALISMAN_ENABLED = True
TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:", "https:"],
        "script-src": ["'self'", "'unsafe-inline'"],
        "style-src": ["'self'", "'unsafe-inline'"],
        "font-src": ["'self'", "data:"],
        "frame-ancestors": ["'none'"],
    }
}

Start in Content-Security-Policy-Report-Only mode to identify legitimate violations before enforcing.

Measure 10 — Optional IP restrictions

For internal deployments, restrict to an IP range via ingress:

nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/16,10.0.0.0/8"

5. Data and permissions (measures 11 to 13)

Measure 11 — Row Level Security

For each multi-tenant dataset, configure RLS rules in Settings → Row Level Security. Example: a user only sees rows where tenant_id = current_user.tenant. Without this, a Gamma user can potentially see other tenants' data via SQL Lab.

Measure 12 — SQL Lab restrictions

SQL Lab gives direct database access. Restrict via roles:

Remove can_sql_json from Gamma role;
Disable can_csv if CSV export not desired;
Limit accessible databases via DB_CONNECTION_MUTATOR.

Measure 13 — Read-only DB accounts

Credentials registered in Superset to connect to your analytical databases must be read-only. Otherwise, a SQL Lab user can DROP TABLE.

-- Postgres
CREATE ROLE superset_reader WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE prod TO superset_reader;
GRANT USAGE ON SCHEMA public TO superset_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO superset_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO superset_reader;

6. Audit and observability (measures 14 to 15)

Measure 14 — Audit log enabled

FAB_API_SWAGGER_UI = False
LOG_LEVEL = "INFO"
EVENT_LOGGER = DBEventLogger()

Stream logs to an external system (Loki, ELK, Datadog) with 90-day retention minimum for compliance.

Measure 15 — Anomaly detection

Set up alerts on:

More than 10 login failures in 5 minutes for the same user (brute-force);
SQL Lab query exceeding abnormal volume (data exfiltration);
Mass dashboard creation/deletion (compromised account);
Login from unusual country (geo-IP).

7. Bonus measures (beyond the 15)

Upstream WAF: Cloudflare, AWS WAF, or ModSecurity to filter malicious requests;
Secret rotation: SECRET_KEY every 12 months, DB passwords every 6 months;
Encryption at rest: encrypted Kubernetes volumes, encrypted metadata DB;
Kubernetes network policies: restrict pod-to-pod flows to bare necessity;
Image scanning: Trivy or Snyk in CI to detect CVEs in the Superset image;
Annual pen-test: have the instance audited by a third party once per year.

8. The trap of experimental feature flags

Superset offers feature flags for stabilizing features. Some carry security risks:

VERSIONED_EXPORT: may expose secrets in exports if misconfigured;
PRESTO_EXPAND_DATA: may generate heavy queries by accident;
ENABLE_TEMPLATE_PROCESSING: enables Jinja execution, hence potentially arbitrary code if poorly restricted.

Only enable a feature flag after reading its documentation and understanding its security impact.

9. How to check your level?

Measures applied	Level
0-5	Critical: do not expose in production
6-10	Acceptable for controlled internal use
11-13	Healthy production, minimum compliance
14-15+	Strong posture, comparable to ISO 27001 requirements

10. Automated scanning tools

Trivy: Docker image CVE scanning;
kube-bench: CIS Kubernetes Benchmark audit;
OWASP ZAP: web surface scan;
SSL Labs: certificate and TLS config testing;
Lighthouse: HTTP security headers audit.

11. Compliance and certifications

For regulated organizations (GDPR, ISO 27001, SOC 2, HDS), see our dedicated articles on the production checklist and the managed vs self-hosted comparison. Most of these 15 measures are prerequisites for compliance.

This configuration is automatically managed by TVL Managed Superset, which applies these 15 measures by default on delivered instances.

12. FAQ

Is Apache Superset secure by default?

No. The default configuration is for development: admin/admin account, demo SECRET_KEY, no CSP, no HTTPS. Any production deployment requires explicit hardening.

How long to apply these 15 measures?

For an experienced team: 3 to 5 days. For a team new to Superset: 5 to 10 days, mainly on SSO integration and RLS configuration which require deep understanding of the permission model.

Is SQL Lab dangerous?

SQL Lab gives direct SQL access to connected databases. Dangerous if: (1) credentials have write rights, (2) open to non-trusted users, (3) connected databases contain sensitive data not filtered by RLS. Harden all three together.

Do you need a WAF in front of Apache Superset?

Recommended for any public exposure. Cloudflare, AWS WAF, or ModSecurity filter common attacks (injection, XSS, brute-force).

Recommended pen-test frequency?

Annual for public exposure with sensitive data. Every two years for internal use. After every major architecture change, redo a targeted test.

13. Conclusion

Securing Apache Superset is no harder than securing any other Flask application in production, but it requires rigor. The 15 measures listed cover the most frequent attack vectors. Beyond come continuous operational security (quarterly permission reviews, annual audits, operator training), which makes up 50% of real posture. Security is not a state but a process: this checklist serves as a starting point, not a destination.

Want the benefits of Apache Superset without the friction of installation and maintenance? Deploy your instance in 3 clicks with TVL Managed Superset, hosted in Europe (OVHcloud, Roubaix, France).