feat(sharing): enforce sharing config as server-side security#9578
Merged
Conversation
mode Gate the read_code and export_as_html endpoints behind the existing sharing.wasm and sharing.html config flags respectively. Previously these flags only hid UI buttons, leaving the underlying APIs callable directly. Now the server returns 403 (surfaced as 401 by the error handler) when the relevant flag is false. Also gates the "Create molab notebook" menu item behind sharingWasmEnabled, which was the only sharing action with no visibility control.
Block `marimo export html-wasm` entirely when sharing.wasm = false. Default `--no-include-code` for `marimo export html` when either sharing.wasm or sharing.html is false, so code is absent from the output without requiring per-invocation flags.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
There was a problem hiding this comment.
Pull request overview
Enforces the existing sharing.wasm and sharing.html configuration flags as real server-side controls (not just UI hints) on the marimo edit server endpoints, and hides the corresponding "Create molab notebook" action in the editor when sharing.wasm is disabled.
Changes:
POST /api/kernel/read_codenow returns 403 whensharing.wasm = false.POST /api/export/htmlnow returns 403 whensharing.html = false.- The "Create molab notebook" Share dropdown item is hidden when
sharing.wasmis disabled, matching the existing WebAssembly-link gating.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| marimo/_server/api/endpoints/files.py | Adds a server-side sharing.wasm check in read_code and updates the OpenAPI 403 description. |
| marimo/_server/api/endpoints/export.py | Adds a server-side sharing.html check in export_as_html and updates the OpenAPI 403 description. |
| frontend/src/components/editor/actions/useNotebookActions.tsx | Hides the "Create molab notebook" action when sharingWasmEnabled is false. |
| tests/_server/api/endpoints/test_files.py | Adds a test that read_code is blocked when sharing.wasm = false. |
Contributor
There was a problem hiding this comment.
No issues found across 4 files
Architecture diagram
sequenceDiagram
participant User as Browser User
participant UI as Editor UI
participant API as Server API
participant Config as Config Manager
participant FS as File System
Note over User,FS: Server-Side Sharing Enforcements
User->>UI: Click "Create molab notebook"
UI->>UI: Check sharingWasmEnabled flag
alt sharing.wasm = false
UI->>UI: Hide action button (no request sent)
else sharing.wasm = true (or unset)
UI->>API: POST /api/kernel/read_code
API->>Config: get_config()
Config-->>API: {sharing: {wasm: true/false, html: true/false}}
alt sharing.wasm = false
API->>API: Return 403 Forbidden
API-->>UI: Error response
else sharing.wasm != false
API->>FS: Read notebook source
FS-->>API: Source code
API-->>UI: Source code
end
end
User->>UI: Click "Export HTML"
UI->>API: POST /api/export/html
API->>Config: get_config()
Config-->>API: {sharing: {html: true/false}}
alt sharing.html = false
API->>API: Return 403 Forbidden
API-->>UI: Error response
else sharing.html != false
API->>FS: Generate HTML export
FS-->>API: HTML content
API-->>UI: Downloaded file
end
Note over User,FS: CLI Export Paths
User->>FS: Run marimo export html-wasm
FS->>Config: Resolve sharing config
alt sharing.wasm = false
FS->>FS: Raise UsageError, abort
else sharing.wasm != false
FS->>FS: Generate WASM export
end
User->>FS: Run marimo export html
FS->>Config: Resolve sharing config
alt sharing.html = false OR sharing.wasm = false
FS->>FS: Auto-apply --no-include-code
else sharing controls enabled
FS->>FS: Use user-provided --include-code flag
end
FS->>FS: Generate HTML with/without source code
Note over User,FS: Config Resolution Chain
User->>Config: Provide pyproject.toml
User->>Config: Provide user config (~/.config/marimo/marimo.toml)
User->>Config: Provide env vars
Config->>Config: Merge configs (project > user > env)
Config-->>API: Resolved sharing settings
Config-->>FS: Resolved sharing settings
mscolnick
previously approved these changes
May 18, 2026
Contributor
|
thanks @nojaf, the PR description might be outdated as it references the CLI. i do think we should not change that codepath anyways though |
Contributor
Author
|
@mscolnick ah sorry, I did not push my second commit it seems. |
enforcement Injects sharing.wasm = false and sharing.html = false into the config resolution chain via EnvConfigManager when set, taking precedence over all per-project and per-user config. Intended for devpod/container environments where infra sets the variable and all notebooks inherit it without requiring per-project configuration.
Contributor
|
|
button Rather than blocking CLI export commands (which are local operations), thread the resolved sharing config through all export paths so it is embedded in the generated HTML. The static banner reads sharing.wasm from the embedded config and conditionally hides the "Open in molab" button. This prevents a hosted WASM or static HTML file from offering an easy one-click path to send source code to an external service. Covers all export paths: CLI (export_as_wasm, run_app_then_export_as_wasm, run_app_then_export_as_html), server endpoint, and picks up MARIMO_RESTRICT_SHARING automatically via EnvConfigManager.
Contributor
Author
|
@mscolnick I removed the env var so that can be added later. |
Bundle ReportChanges will increase total bundle size by 126.6kB (0.5%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: marimo-esmAssets Changed:
Files in
Files in
Files in
|
Contributor
|
This breaks the "Download as Python" flow, which is not exactly sharing. This is not hidden in the UI and would throw a server error. |
The read_code endpoint is used by several local operations (Download Python code, Copy code to clipboard) that have nothing to do with external sharing. Blocking it via sharing.wasm broke those flows with an unexpected server error while the buttons remained visible in the UI. Only the HTML export endpoint warrants a server-side sharing gate, since it is a server-driven operation. The wasm/molab sharing flow constructs URLs entirely client-side and is already gated at the UI layer.
Exporting != sharing. Blocking POST /api/export/html when sharing.html is false prevented legitimate local downloads (Download as HTML) with no security benefit, since the user already has the source in the editor. The sharing config is still baked into exported HTML so the static banner's molab button respects the flag. Enforcement stays at the UI layer, which is what the maintainer intended.
Contributor
Author
|
@mscolnick, right, I removed those checks in the api endpoints. |
Contributor
Author
|
Hi @manzt, @akshayka or @dmadisetti, as Myles is out I was wondering if anyone could take over here. Thanks! |
Light2Dark
previously approved these changes
Jun 1, 2026
Light2Dark
reviewed
Jun 1, 2026
akshayka
reviewed
Jun 1, 2026
akshayka
left a comment
Contributor
There was a problem hiding this comment.
Hey nojaf, thanks for this PR.
For the configuration, can we introduce a third optional field, molab, instead of riding on the wasm field?
dmadisetti
previously approved these changes
Jun 1, 2026
dmadisetti
left a comment
Member
There was a problem hiding this comment.
Thanks for the clean up too!
Annotate the static-notebook config as MarimoConfig so display and sharing assignments type-check without casts or type: ignore, and remove the now-redundant DisplayConfig casts in the export helpers.
Gate the "Create molab notebook" action and the exported HTML "Open in molab" button on a new sharing.molab flag instead of riding on sharing.wasm, so molab sharing can be disabled independently of WebAssembly links.
Light2Dark
approved these changes
Jun 2, 2026
Contributor
Author
|
Thanks for all the reviews and feedback! I think the failing Windows build is unrelated to my changes, looks like a timeout. Let me know if this needs any more changes. |
Member
|
Thank you! |
6 tasks
dmadisetti
pushed a commit
that referenced
this pull request
Jun 4, 2026
## 📝 Summary <!-- If this PR closes any issues, list them here by number (e.g., Closes #123). Detail the specific changes made in this pull request. Explain the problem addressed and how it was resolved. If applicable, provide before and after comparisons, screenshots, or any relevant details to help reviewers understand the changes easily. --> This is a follow up to #9578. That PR made the `sharing.wasm`, `sharing.html`, and `sharing.molab` config flags control what sharing affordances the UI surfaces, and added the `molab` flag. During #9578 the maintainers (@mscolnick via DM) asked that the `MARIMO_RESTRICT_SHARING` env var be split out into its own PR, so this is that separate change. ### What changed - **`marimo/_config/settings.py`**: add `RESTRICT_SHARING` to `GlobalSettings`, reading the `MARIMO_RESTRICT_SHARING` env var. - **`marimo/_config/manager.py`**: when the env var is set, `EnvConfigManager.get_config()` injects `sharing = {"wasm": False, "html": False, "molab": False}`. `EnvConfigManager` is the last (highest priority) partial in `get_default_config_manager`, so this override takes precedence over any per-project or per-user TOML config. - **`tests/_config/test_manager.py`**: tests that the flag injects the all-false sharing config, that nothing is injected when the flag is off, and that the env override wins over a user config that explicitly enables sharing. ### Why we want this The `sharing.*` config flags require every project or user to opt in. In our company we run marimo in managed devpod/container environments, and there is no reliable way to ensure every user has the flag set in their own config, since users have admin access to their own environment and can edit config files. `MARIMO_RESTRICT_SHARING=1` lets infra admins set the restriction once at the container/pod spec level, outside the user's control, and have every notebook session inherit it without per-project configuration. ### Scope and honest framing This is a UI-hiding/policy control, not a server-side security boundary. #9578 deliberately removed the server-side 403 gates (`exporting != sharing`), so the sharing config only drives what the UI surfaces (the editor Share dropdown and the molab button baked into exported HTML). This env var hides those affordances machine-wide but does not block a determined user: exported HTML still embeds source and endpoints still serve code. We pair it with network egress filtering (blocking `marimo.app`, `molab.marimo.io`, `static.marimo.app`) for defence in depth. Note also that `MARIMO_RESTRICT_SHARING=0` as a command prefix overrides the env var for that process, so it should be set in the devpod/container spec rather than inside the container. ## 📋 Pre-Review Checklist <!-- These checks need to be completed before a PR is reviewed --> - [x] For large changes, or changes that affect the public API: this change was discussed or approved through an issue, on [Discord](https://marimo.io/discord?ref=pr), or the community [discussions](https://github.com/marimo-team/marimo/discussions) (Please provide a link if applicable). <!-- Discussed during review of #9578, where maintainers asked for this to be a separate PR. --> - [x] Any AI generated code has been reviewed line-by-line by the human PR author, who stands by it. - [ ] Video or media evidence is provided for any visual changes (optional). <!-- N/A: backend config only, no visual changes. --> ## ✅ Merge Checklist - [x] I have read the [contributor guidelines](https://github.com/marimo-team/marimo/blob/main/CONTRIBUTING.md). - [x] Documentation has been updated where applicable, including docstrings for API changes. - [x] Tests have been added for the changes made. //cc @Light2Dark @akshayka, @dmadisetti
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 Summary
Closes #6318
This PR makes the existing
sharing.wasmandsharing.htmlconfiguration flags control what the UI surfaces, so users cannot accidentally share notebook source code through molab or WebAssembly links. Previouslysharing.wasmonly hid "Create WebAssembly link" — the "Create molab notebook" button was left fully ungated, and exported HTML files showed the "Open in molab" button regardless of config.What changed
marimo edit(live server)Share → Create molab notebookwas not gated at all. It now respectssharing.wasm = falseand is hidden alongside the "Create WebAssembly link" item.Exported HTML files (static and WASM)
The sharing config is now baked into the
user_configJSON embedded in exported HTML. TheStaticBannercomponent readssharing.wasmfrom this embedded config and conditionally hides the "Open in molab" button. This means a hosted WASM notebook or a shared static HTML file will not offer an easy one-click path to send source code to an external service when the flag is set.Important limitation: hiding the molab button is a convenience measure, not a security control. A WASM HTML file always embeds the full source code (Pyodide requires it to run the notebook). Anyone who receives the file can read the source directly from the HTML, and can trivially reconstruct a molab URL themselves — the lz-string compression used in those URLs is a well-known open-source scheme, reversible with any standard lz-string library. Blocking
molab.marimo.ioat the network level prevents the link from being opened in molab but does not prevent the source from being extracted from the file and shared by other means.Configuration
Per-project or per-user — committed
pyproject.tomlor user config:Compliance
The risk
Several marimo features encode the full notebook source code and make it trivially accessible outside the organisation:
lz-stringand embed it in a URL hash fragment (https://marimo.app/#code/...). The encoding is not encryption — it is a well-known open-source compression scheme that any developer can decode in seconds with freely available tools.For organisations with proprietary notebooks, model code, or data pipelines, these paths can result in unintended IP disclosure — including accidental sharing by well-meaning users who don't realise what the link or file contains.
Honest threat model
These controls reliably prevent accidental disclosure and enforce policy for compliant users. They are not designed to stop a determined insider who has shell access to their own environment. Exporting to HTML or downloading Python code remains unrestricted — exporting is not sharing.
For defence-in-depth, pair this config with network egress filtering: block outbound traffic to
marimo.app,molab.marimo.io, andstatic.marimo.appat the infrastructure level. That control is independent of marimo and cannot be bypassed by editing a config file.Deployment recommendation
Commit
[tool.marimo.sharing] wasm = falsetopyproject.tomlin repositories that contain proprietary notebooks. Pair with network egress filtering on the external marimo domains for defence-in-depth.📋 Pre-Review Checklist
✅ Merge Checklist