cbcfd9599f
Snapshots all four versioned Docusaurus sections at v6.1.0. Built on top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions so the snapshot benefits from: - Auto-gen refresh before snapshotting (database pages from engine spec metadata, API reference from openapi.json, component pages from Storybook stories) — captured at the SHA we cut from rather than whatever happened to be on disk. - Data-import freeze: country list, feature flag table, database diagnostics, and component metadata are copied into snapshot-local `_versioned_data/` dirs so the historical version doesn't silently mutate when the source files change. - Depth-aware import-path rewriter that handles deeply-nested component MDX files referencing `../../../src/` from the snapshot. Versioning behavior: `lastVersion` stays at `current` for every section, so the canonical URLs (`/docs/...`, `/admin-docs/...`, `/developer-docs/...`, `/components/...`) continue to render content from master. The `current` version is consistently labeled "Next" with an `unreleased` banner, and `6.1.0` is a historical pin accessible only via its explicit version segment. Component playground: previously `disabled: true` in versions-config.json, now enabled and versioned. The plugin block in docusaurus.config.ts was already gated only by the `disabled` flag, so no other code changes were needed to bring it back online. The frozen `databases.json` in the snapshot is the canonical 80-database artifact from the latest committed state in master (preserved by the generator's input-hash cache), not a fallback regenerated from a local Flask environment.
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.