Specific security tasks for a production Superset: roles and data access, secret key and sessions, headers, SQL execution limits, database privileges, export controls, patching and testing.
Choosing which built-in role each user population gets, why Admin and Alpha are over-assigned in most rollouts, what Gamma users can and cannot do, and how superset init resets edited roles.
Building data access roles on top of Gamma: per-dataset, per-schema and per-database permissions, combining roles, all_database_access risks and keeping custom roles stable across upgrades.
Controlling who sees which dashboards: dataset-based access versus dashboard role access with DASHBOARD_RBAC, published versus draft dashboards and avoiding dashboards that leak through shared datasets.
Generating, storing and rotating SECRET_KEY: PREVIOUS_SECRET_KEY and the re-encrypt command, why reused keys enable session forgery across environments, and the response plan if the key leaks.
Moving from cookie sessions to a Redis or database session backend so logout really ends sessions, setting lifetime and cookie flags, and the SameSite trade-off for iframe embedding.
Enabling Talisman and tuning the Content Security Policy for maps, fonts and embedding, HSTS, frame options and testing headers without breaking dashboards.
Limiting what users can run: DML off by default per database, DISALLOWED_SQL_FUNCTIONS additions in 5.0 and 6.0, query row limits, per-database SQL Lab exposure and auditing executed queries.
Designing the warehouse accounts Superset uses: read-only users, schema scoping, separate connections per sensitivity level, per-user impersonation where engines support it, and network restrictions.
Controlling CSV, Excel, JSON, image and clipboard exports by role with granular export permissions, and what that does and does not prevent for users who can see the data.
Tracking Superset CVEs by release, separating application vulnerabilities from container image findings, planning patch upgrades and testing permissions after each one.
Scoping a security test of Superset: authentication and session handling, role and RLS bypass attempts, Jinja and SQL injection paths, guest token handling for embedding and exposed API endpoints.
A pre-go-live checklist for Superset: TLS at the proxy, unique secret key, server-side sessions, IdP login, least-privilege roles and database users, Talisman, disabled default admin, WAF and logging.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.