marimo notebooks need a token and an execution boundary

marimo turns Python notebooks into web applications. An edit server can create and run cells. An app server can expose a notebook interface with inputs and outputs. Both modes can be useful for data analysis, internal tools and demonstrations. Both can execute code in the context of the deployment.

The marimo deployment documentation describes token-based authentication. The Kubernetes guide shows an auth setting with token as the default and none as an option that disables authentication. That switch should be treated as a deliberate exposure decision.

Counts and interpretation

At 06:47 Asia/Shanghai on 2026-11-09, the count-only ZoomEye measurement used the all scope, page 1 and page size 1:

  • app="marimo": 14,147
  • title="marimo": 14,781
  • http.body="marimo notebook": 30

The app query is the narrow product signal. The title count is slightly larger. The body phrase is much smaller because the page text is a weaker fingerprint. A match does not prove that code execution is available to the visitor.

Editor and app are different risks

An editor session can modify notebook code, install packages, read mounted files and access environment variables. A read-only app may still evaluate cells when a user changes inputs. The server should separate the two modes and assign a different network boundary to each.

Do not mount a production secret into a notebook that is reachable by an untrusted audience. Use a dedicated service account with a narrow role, a read-only data view and an outbound network policy. If the notebook needs a write operation, make that operation an explicit backend service with its own authorization checks.

Manage the token

Keep the token in a secret manager or a protected password file. The marimo deployment guidance includes token-password-file workflows. Use a unique token per environment, avoid command-line history and rotate it when a user or deployment changes.

When a reverse proxy handles login, verify that it sets the marimo authentication state instead of forwarding a client-supplied header. A public app behind a proxy can still be edited if the proxy exposes the editor route or if the notebook server is reachable on a second port.

Limit the runtime

Set CPU, memory and execution time limits. A notebook can loop indefinitely or read a large input. If a user-controlled cell can run arbitrary Python, the process boundary should be strong enough to contain mistakes and malicious input. Consider a disposable sandbox for untrusted notebooks.

Review package installation, file mounts, database connections and environment variables together. A read-only UI can still make destructive calls through code the author wrote. The data access layer is part of the security model.

A deployment check

  1. Open the editor without a token from a non-management network.
  2. Confirm that the app route is separate from the editor route.
  3. Inspect the mounted secrets and outbound connections.
  4. Try to read a file outside the notebook workspace.
  5. Change an app input and observe whether a write occurs.
  6. Rotate the token and verify that the old value fails.

The observed marimo counts show a meaningful public footprint for a product that can execute Python. The useful security question is not only whether the page loads. It is whether the visitor can reach an editor, alter code, read a mount or start a long-running job. Require a token, separate app and editor modes and give the kernel only the resources it needs.

References