0fb7fc2721
Major restructuring of documentation to separate concerns: **New Structure:** - `/docs/` - User-facing docs (intro, quickstart, databases, using-superset, faq) - `/admin-docs/` - Administrator docs (installation, configuration, security) - `/developer-docs/` - Developer docs (contributing, extensions, guidelines, testing) **Changes:** - Move installation, configuration, and security docs to admin_docs/ - Move contributing, extensions, guidelines, and testing to developer_docs/ - Rename developer_portal to developer_docs (with underscore to hyphen in URL) - Add sidebarAdminDocs.js for admin documentation navigation - Update versions-config.json with new doc sections - Update docusaurus.config.ts with new plugins and redirects - Update internal links in versioned docs (6.0.0) to use new paths - Keep user-facing content (databases, using-superset, faq) in main docs This separation makes it clearer which documentation is relevant for: - End users exploring and visualizing data - Administrators deploying and configuring Superset - Developers contributing to or extending Superset Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2.4 KiB
title, sidebar_position
| title | sidebar_position |
|---|---|
| Security | 9 |
Security
By default, extensions are disabled and must be explicitly enabled by setting the ENABLE_EXTENSIONS feature flag. Built-in extensions are included as part of the Superset codebase and are held to the same security standards and review processes as the rest of the application.
For external extensions, administrators are responsible for evaluating and verifying the security of any extensions they choose to install, just as they would when installing third-party NPM or PyPI packages. At this stage, all extensions run in the same context as the host application, without additional sandboxing. This means that external extensions can impact the security and performance of a Superset environment in the same way as any other installed dependency.
We plan to introduce an optional sandboxed execution model for extensions in the future (as part of an additional SIP). Until then, administrators should exercise caution and follow best practices when selecting and deploying third-party extensions. A directory of community extensions is available in the Community Extensions page. Note that these extensions are not vetted by the Apache Superset project—administrators must evaluate each extension before installation.
Any performance or security vulnerabilities introduced by external extensions should be reported directly to the extension author, not as Superset vulnerabilities.
Any security concerns regarding built-in extensions (included in Superset's monorepo) should be reported to the Superset Security mailing list for triage and resolution by maintainers.