Superset Security Configuration#

Superset's production security posture is controlled by a handful of settings in superset/config.py and enforced at startup. All settings can be overridden in a local superset_config.py.

SECRET_KEY#

The SECRET_KEY is used to sign session cookies and encrypt sensitive data. The default falls back to the CHANGE_ME_SECRET_KEY constant ("CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET") if the SUPERSET_SECRET_KEY environment variable is unset 1.

Startup enforcement: On every init_app(), Superset calls check_secret_key(). In debug/test mode it logs a prominent warning banner; in production it calls sys.exit(1) — the application refuses to start with a default key 2.

Distributed deployments: All web server pods and Celery worker pods must share the identical SECRET_KEY. A mismatch causes workers to fail session decryption, which surfaces as misleading "Invalid login" errors rather than a clear configuration error 3.

DEBUG Flag#

DEBUG is derived from the FLASK_DEBUG environment variable at startup 4. It controls two orthogonal behaviors:

Error Rendering#

When DEBUG=False and a browser (HTML-accepting) client encounters a 404 or 500, Superset serves a pre-built static HTML error page (404.html / 500.html). When DEBUG=True, it returns a JSON response instead. In both cases, stack traces are never sent to the client — they are always logged server-side via exc_info=True 5.

This pattern applies consistently across three handlers in error_handling.py: HTTPException (line 163), CommandException (line 188), and the catch-all Exception handler (line 211).

CSP / Talisman Config Selection#

During middleware initialization, DEBUG=True selects TALISMAN_DEV_CONFIG (which permits 'unsafe-inline' and 'unsafe-eval' for React hot-reload), while production uses the stricter TALISMAN_CONFIG 6.

Flask-Talisman and CSP#

Flask-Talisman enforces HTTP security headers and Content Security Policy. It is disabled by default (TALISMAN_ENABLED = False) 7 and must be explicitly enabled for production.

Key defaults in TALISMAN_CONFIG:

• script-src: 'self' + 'strict-dynamic' with per-request nonces
• object-src: 'none'
• force_https: False (intentional — see Reverse Proxy section below)
• session_cookie_secure: False

When Talisman is disabled, Superset logs a startup warning urging operators to configure CSP via an alternative mechanism 8. Override TALISMAN_CONFIG in superset_config.py to customize; see the official networking docs for guidance 9.

Session Cookie Configuration#

Defaults in config.py 10:

Warning: Setting SESSION_COOKIE_SECURE = True while Celery workers call Superset over plain HTTP (e.g., WEBDRIVER_BASEURL = "http://...") will cause session cookies to be silently dropped, breaking Alerts & Reports screenshot generation 9.

CSRF Protection#

CSRF is enabled by default (WTF_CSRF_ENABLED = True) 11 with a one-week token lifetime 12. A small set of API endpoints are exempt 13:

• superset.views.core.log
• superset.views.core.explore_json
• superset.charts.data.api.data
• superset.dashboards.api.cache_dashboard_screenshot

Reverse Proxy / Distributed Deployment Consistency#

When TLS is terminated at a proxy (nginx, Traefik, etc.):

1. ENABLE_PROXY_FIX = True — required so Flask reconstructs the correct scheme and client IP from X-Forwarded-* headers 9.
2. force_https: False in Talisman — do not set this to True behind a TLS-terminating proxy; it creates redirect loops and breaks Celery worker calls 9.
3. WEBDRIVER_BASEURL (default http://0.0.0.0:8080/) — the internal URL used by Celery workers. Keep this as http:// if TLS is terminated at the proxy 14.
4. WEBDRIVER_BASEURL_USER_FRIENDLY — set this to the external HTTPS URL so notification emails contain valid links 14.
5. Identical SECRET_KEY and SQLALCHEMY_DATABASE_URI across all web and worker pods — mismatches cause silent session decryption failures 15.

Quick Reference: Key Security Settings#