Securing Your Superset Installation for Production

This guide applies to Apache Superset version 4.0 and later and is an evolving set of best practices that administrators should adapt to their specific deployment architecture.

The default Apache Superset configuration is optimized for ease of use and development, not for security. For any production deployment, it is critical that you review and apply the following security configurations to harden your instance, protect user data, and prevent unauthorized access.

This guide provides a comprehensive checklist of essential security configurations and best practices.

Critical Prerequisites: HTTPS/TLS Configuration

Running Superset without HTTPS (TLS) is not secure. Without it, all network traffic—including user credentials, session tokens, and sensitive data—is sent in cleartext and can be easily intercepted.

• Use a Reverse Proxy: Your Superset instance should always be deployed behind a reverse proxy (e.g., Nginx, Traefik) or a load balancer (e.g., AWS ALB, Google Cloud Load Balancer) that is configured to handle HTTPS termination.
• Enforce Modern TLS: Configure your proxy to enforce TLS 1.2 or higher with strong, industry-standard cipher suites.
• Implement HSTS: Use the HTTP Strict Transport Security (HSTS) header to ensure browsers only connect to your Superset instance over HTTPS. This can be configured in your reverse proxy or within Superset's Talisman settings.

SUPERSET_SECRET_KEY Management (CRITICAL)

This is the most critical security setting for your Superset instance. It is used to sign all session cookies and encrypt sensitive information in the metadata database, such as database connection credentials.

• Generate a Unique, Strong Key: A unique key must be generated for every Superset instance. Use a cryptographically secure method to create it.

  # Example using openssl to generate a strong key
  openssl rand -base64 42

• Store the Key Securely: The key must be kept confidential. The recommended approach is to store it as an environment variable or in a secrets management system (e.g., AWS Secrets Manager, HashiCorp Vault). Do not hardcode the key in superset_config.py or commit it to version control.

  # In superset_config.py
  import os
  SECRET_KEY = os.environ.get('SUPERSET_SECRET_KEY')

⚠️ Warning: Your SUPERSET_SECRET_KEY Must Be Unique

NEVER reuse the same SUPERSET_SECRET_KEY across different environments (e.g., development, staging, production) or different Superset instances. Reusing a key allows cryptographically signed session cookies to be used across those instances, which can lead to a full authentication bypass if a cookie is compromised. Treat this key like a master password.

Session Management Security (CRITICAL)

Properly configuring user sessions is essential to prevent session hijacking and ensure that sessions are terminated correctly.

Use a Server-Side Session Backend (Strongly Recommended for Production)

The default stateless cookie-based session handling presents challenges for immediate session invalidation upon logout. For all production deployments, we strongly recommend configuring an optional server-side session backend like Redis, Memcached, or a database. This ensures that session data is stored securely on the server and can be instantly destroyed upon logout, rendering any copied session cookies immediately useless.

Example superset_config.py for Redis:

# superset_config.py
from redis import Redis
import os

# 1. Enable server-side sessions
SESSION_SERVER_SIDE = True

# 2. Choose your backend (e.g., 'redis', 'memcached', 'filesystem', 'sqlalchemy')
SESSION_TYPE = 'redis'

# 3. Configure your Redis connection
# Use environment variables for sensitive details
SESSION_REDIS = Redis(
    host=os.environ.get('REDIS_HOST', 'localhost'),
    port=int(os.environ.get('REDIS_PORT', 6379)),
    password=os.environ.get('REDIS_PASSWORD'),
    db=int(os.environ.get('REDIS_DB', 0)),
    ssl=os.environ.get('REDIS_SSL_ENABLED', 'True').lower() == 'true',
    ssl_cert_reqs='required' # Or another appropriate SSL setting
)

# 4. Ensure the session cookie is signed for integrity
SESSION_USE_SIGNER = True

Configure Session Lifetime and Cookie Security Flags

This is mandatory for all deployments, whether stateless or server-side.

# superset_config.py
from datetime import timedelta

# Set a short absolute session timeout
# The default is 31 days, which is NOT recommended for production.
PERMANENT_SESSION_LIFETIME = timedelta(hours=8)

# Enforce secure cookie flags to prevent browser-based attacks
SESSION_COOKIE_SECURE = True      # Transmit cookie only over HTTPS
SESSION_COOKIE_HTTPONLY = True    # Prevent client-side JS from accessing the cookie
SESSION_COOKIE_SAMESITE = 'Lax'   # Provide protection against CSRF attacks

Note on iFrame Embedding and SESSION_COOKIE_SAMESITE

The recommended default setting 'Lax' provides good CSRF protection for most use cases. However, if you need to embed Superset dashboards into other applications using an iFrame, you will need to change this setting to 'None'.

SESSION_COOKIE_SAMESITE = 'None'

Setting SameSite to 'None' requires that SESSION_COOKIE_SECURE is also set to True. Be aware that this configuration disables some of the browser's built-in CSRF protections to allow for cross-domain functionality, so it should only be used when iFrame embedding is necessary.

Authentication and Authorization

While Superset's built-in database authentication is convenient, for production it's highly recommended to integrate with an enterprise-grade identity provider (IdP).

• Use an Enterprise IdP: Configure authentication via OAuth or LDAP to leverage your organization's existing identity management system. This provides benefits like Single Sign-On (SSO), Multi-Factor Authentication (MFA), and centralized user provisioning/deprovisioning.
• Principle of Least Privilege: Assign users to the most restrictive roles necessary for their jobs. Avoid over-provisioning users with Admin or Alpha roles, and ensure row-level security is applied where appropriate.
• Admin Accounts: Delete or disable the default admin user after a new administrative account has been configured.

Content Security Policy (CSP) and Other Headers

Superset can use Flask-Talisman to set security headers. However, it must be explicitly enabled.

⚠️ Important: Talisman is Disabled by Default

In Superset 4.0 and later, Talisman is disabled by default (TALISMAN_ENABLED = False). You must explicitly enable it in your superset_config.py for the security headers defined in TALISMAN_CONFIG to take effect.

Here's the documentation section how how to set up Talisman: https://superset.apache.org/docs/security/#content-security-policy-csp

Database Security

❗ Superset is Not a Database Firewall

It is essential to understand that Apache Superset is a data visualization and exploration platform, not a database firewall or a comprehensive security solution for your data warehouse. While Superset provides features to help manage data access, the ultimate responsibility for securing your underlying databases lies with your database administrators (DBAs) and security teams. This includes managing network access, user privileges, and fine-grained permissions directly within the database. The configurations below are an important secondary layer of security but should not be your only line of defense.

• Use a Dedicated Database User: The database connection configured in Superset should use a dedicated, limited-privilege database user. This user should only have the minimum required permissions (e.g., SELECT on specific schemas) for the data sources it needs to query. It should not have INSERT, UPDATE, DELETE, or administrative privileges.
• Restrict Dangerous SQL Functions: To mitigate potential SQL injection risks, configure the DISALLOWED_SQL_FUNCTIONS list in your superset_config.py. Be aware that this is a defense-in-depth measure, not a substitute for proper database permissions.

Additional Security Layers

• Web Application Firewall (WAF): Deploying Superset behind a WAF (e.g., Cloudflare, AWS WAF) is strongly recommended. A WAF with a standard ruleset (like the OWASP Core Rule Set) provides a critical layer of defense against common attacks like SQL Injection, XSS, and remote code execution.

Monitoring and Logging

• Configure Structured Logging: Set up a robust logging configuration to capture important security events.
• Centralize Logs: Ship logs from all Superset components (frontend, worker, etc.) to a centralized SIEM (Security Information and Event Management) system for analysis and alerting.
• Monitor Key Events: Create alerts for suspicious activities, including:
  • Multiple failed login attempts for a single user or from a single IP address.
  • Changes to user roles or permissions.
  • Creation or deletion of high-privilege users.
  • Attempts to use disallowed SQL functions.

---

Appendix A: Production Deployment Checklist

Initial Setup:

• HTTPS/TLS is configured and enforced via a reverse proxy.
• A unique, strong SUPERSET_SECRET_KEY is generated and secured in an environment variable or secrets vault.
• Server-side session management is configured (e.g., Redis).
• PERMANENT_SESSION_LIFETIME is set to a short duration (e.g., 8 hours).
• All session cookie security flags (Secure, HttpOnly, SameSite) are enabled.
• DEBUG mode is set to False.
• Talisman is explicitly enabled and configured with a strict Content Security Policy.
• Database connections use dedicated, limited-privilege accounts.
• Authentication is integrated with an enterprise identity provider (OAuth/LDAP).
• A Web Application Firewall (WAF) is deployed in front of Superset.
• Logging is configured and logs are shipped to a central monitoring system.

Ongoing Maintenance:

• Regularly update to the latest major or minor versions of Superset. Those versions receive up-to-date security patches.
• Rotate the SUPERSET_SECRET_KEY periodically (e.g., quarterly) and after any potential security incident.
• Conduct quarterly access reviews for all users.
• Assuming logging and monitoring is in place, review security monitoring alerts weekly.

Appendix B: SECRET_KEY Rotation and Compromise Response

Why and When to Rotate the SECRET_KEY Rotating the SUPERSET_SECRET_KEY is a critical security procedure. It is mandatory after a known or suspected compromise and is a best practice when an employee with access to the key departs. While periodic rotation can limit the window of exposure for an unknown leak, it is a high-impact operation that will invalidate all user sessions and requires careful execution to avoid breaking your instance. The principles behind managing this key align with general best practices for cryptographic storage, which are further detailed in the OWASP Cryptographic Storage Cheat Sheet here: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html

Procedure for Rotating the Key The procedure for safely rotating the SECRET_KEY must be followed precisely to avoid locking yourself out of your instance. The official Apache Superset documentation maintains the correct, up-to-date procedure. Please follow the official guide here: https://superset.apache.org/docs/configuration/configuring-superset/#rotating-to-a-newer-secret_key