sfirke commented on code in PR #35190:
URL: https://github.com/apache/superset/pull/35190#discussion_r2360505312
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
Review Comment:
Feels redundant with the section header.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
Review Comment:
This is great that we are providing a full config here. I wonder if you can
remove what's here
https://superset.apache.org/docs/security/#switching-to-server-side-sessions
and instead point to this guide.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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.
Review Comment:
This section makes sense to me, but do we have any guidance we could point
people toward that shows how to do it? I love that above we are providing
specific config settings, this part seems more vague. If we don't, that
shouldn't block this PR, though.
I think it would be fine to link to external resources about this kind of
log monitoring, since it's hardly a problem unique to Superset.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
Review Comment:
In general I'd like to avoid duplicating any content on
https://superset.apache.org/docs/security/. It makes it harder to keep it
maintained. I like how practical and focused this guide is and would suggest
keeping it as is, but taking a pass through that Security page to find content
that overlaps. Where that exists, you could remove it and replace it with
pointers to sections on this page.
I'd also suggest adding a prominent link from the top of that page to this
page. If this page is going to be "practical guide to securing Superset", what
does that mean for that page? I expect it's "everything else"?
Same goes for this page:
https://superset.apache.org/docs/configuration/networking-settings/
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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/SAML).
+ - [ ] 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 apply Superset security updates.
+ - [ ] Rotate the `SUPERSET_SECRET_KEY` periodically (e.g., quarterly) and
after any potential security incident.
+ - [ ] Conduct quarterly access reviews for all users.
+ - [ ] Review security monitoring alerts weekly.
+
+### **Appendix B: Emergency Procedure for a Compromised `SECRET_KEY`**
+
+If you suspect your `SUPERSET_SECRET_KEY` has been compromised, follow these
steps immediately to contain the incident:
+
+1. **Generate a new `SUPERSET_SECRET_KEY`** using `openssl rand -base64 42`.
+2. **Update the Key:** Update the environment variable or secrets vault with
the new key.
Review Comment:
I believe this is not enough and could cause a catastrophic problem for an
unprepared admin. If I recall correctly, don't you need the prior key in order
to rotate to a new key? I might be mistaken. If we have guidance on rotating to
a new key (I think we do from after the vulnerability about default secret keys
was published), let's link to that from this doc.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
Review Comment:
What do you think of `SESSION_COOKIE_SAMESITE = 'None'` ? This is required
to embed an iFrame of Superset and have it work on a Chrome browser,
https://stackoverflow.com/a/79754758/4470365
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
Review Comment:
```suggestion
'force_https': False, # HTTPS should be handled by a reverse proxy and
workers may need the HTTP route for Alerts & Reports
```
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
Review Comment:
Feels redundant with the first sentence under the header, the one that ends
"... can easily be intercepted". In general, the less often we can repeat
things, the shorter and more readable this guide is.
I do really like how you've organized it into individual security topics.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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/SAML).
+ - [ ] 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 apply Superset security updates.
Review Comment:
```suggestion
- [ ] Regularly update to the latest major or minor versions of Superset.
Those versions receive up-to-date security patches.
```
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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/SAML).
+ - [ ] 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 apply Superset security updates.
+ - [ ] Rotate the `SUPERSET_SECRET_KEY` periodically (e.g., quarterly) and
after any potential security incident.
+ - [ ] Conduct quarterly access reviews for all users.
+ - [ ] Review security monitoring alerts weekly.
+
+### **Appendix B: Emergency Procedure for a Compromised `SECRET_KEY`**
+
+If you suspect your `SUPERSET_SECRET_KEY` has been compromised, follow these
steps immediately to contain the incident:
+
+1. **Generate a new `SUPERSET_SECRET_KEY`** using `openssl rand -base64 42`.
+2. **Update the Key:** Update the environment variable or secrets vault with
the new key.
+3. **Re-encrypt Existing Secrets:** Run the Superset CLI command to
re-encrypt all credentials and other secrets stored in the metadata database
with the new key.
+ ```bash
+ superset re-encrypt-secrets
+ ```
+4. **Restart All Services:** Perform a full restart of all Superset web
servers and workers to ensure they load the new key.
+5. **Invalidate All Sessions:** The key rotation will automatically
invalidate all existing user sessions, forcing all users to log in again.
Review Comment:
If this happens automatically, I don't think it should be a step.
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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/SAML).
+ - [ ] 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 apply Superset security updates.
+ - [ ] Rotate the `SUPERSET_SECRET_KEY` periodically (e.g., quarterly) and
after any potential security incident.
Review Comment:
Why should one rotate the secret key regularly?
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+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.
+
+> #### ⚠️ Warning: Never Run Superset on HTTP in Production
+>
+> Exposing Superset directly over HTTP is a critical security risk that
exposes your entire instance to network interception attacks.
+
+### **`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.
+ ```bash
+ # 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.**
+ ```python
+ # 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 a 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:**
+
+```python
+# 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.
+
+```python
+# 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
+```
+
+### **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, OIDC, SAML,
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.
+
+### **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.
+
+```python
+# superset_config.py
+# The DEBUG flag MUST be set to False in production
+DEBUG = False
+
+# You must explicitly enable Talisman for it to take effect
+TALISMAN_ENABLED = True
+
+# Define a strict Content Security Policy for production
+TALISMAN_CONFIG = {
+ 'content_security_policy': {
+ 'default-src': ["'self'"],
+ 'img-src': ["'self'", 'data:', 'blob:'],
+ 'worker-src': ["'self'", 'blob:'],
+ 'connect-src': [
+ "'self'",
+ 'https://api.mapbox.com',
+ 'https://events.mapbox.com',
+ 'https://tile.openstreetmap.org',
+ 'https://tile.osm.ch',
+ ],
+ 'object-src': "'none'",
+ 'style-src': ["'self'", "'unsafe-inline'"],
+ 'script-src': ["'self'"],
+ },
+ 'force_https': False, # HTTPS should be handled by a reverse proxy
+ 'strict_transport_security': True,
+ 'session_cookie_secure': True,
+ 'frame_options': 'SAMEORIGIN',
+}
+```
+
+### **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/SAML).
+ - [ ] 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 apply Superset security updates.
+ - [ ] Rotate the `SUPERSET_SECRET_KEY` periodically (e.g., quarterly) and
after any potential security incident.
+ - [ ] Conduct quarterly access reviews for all users.
+ - [ ] Review security monitoring alerts weekly.
Review Comment:
I don't think these exist? I would remove this last bullet.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
