Datasette Apps launch: Host custom HTML apps in Datasette

Simon Willison launched a new plugin for Datasette, datasette-apps, on 18th June 2026. The plugin hosts self-contained HTML+JavaScript applications inside tightly constrained iframes on a Datasette instance; a demo is available at agent.datasette.io where users can sign in with GitHub.

How do Datasette Apps work?

Datasette Apps are HTML+JavaScript applications embedded in sandboxed iframes that can run read-only SQL queries and can perform controlled writes via allow-listed stored queries. The iframe uses sandbox="allow-scripts allow-forms" while the app content can include a meta http-equiv="Content-Security-Policy" header that prevents requests to outside hosts, and the parent page exposes a MessageChannel-based transport to accept a small allow-list of operations such as SQL queries.

The sandbox attribute prevents the app from accessing cookies or localStorage and the injected CSP blocks outgoing requests to hosts not on the allow-list. Willison first implemented communication using postMessage but migrated to MessageChannel following a security review, because MessageChannel closes automatically if the page navigates away. Queries requested by an app are verified by the parent before execution, and query and error logs are surfaced back to the iframe for easier debugging. The plugin also includes a create-app flow that produces a copyable prompt containing database schemas so an LLM can be asked to generate app code.

How are write operations and security handled?

Write operations are possible only through Datasette’s stored queries feature and only if a specific stored write query is allow-listed for an app. Datasette 1.0a31 upgraded and rebranded "canned queries" to stored queries; the datasette-apps workflow demonstrates this by calling datasette.storedQuery("todos","add_todo", {...}) in examples that include a due_date value of "2026-06-20". To prevent a malicious app from exfiltrating data via CSP allow-lists, a new apps-set-csp permission restricts which users may set arbitrary CSP hosts. Site administrators can also set allowed_csp_origins in the Datasette configuration so regular users can only pick from approved hosts.

Willison documented a concrete attack scenario discovered during testing: a less privileged user could create an app that queries all tables and exfiltrates data to an allow-listed host, then trick an administrator into visiting that app and running queries as the administrator. The apps-set-csp permission and allowed_csp_origins configuration are the direct mitigations implemented in response.

Why it matters

Datasette Apps moves Datasette beyond a read-only data server and into a platform for building bespoke interfaces that can interact with stored data in a controlled way. The plugin stitches together immutable iframe CSP, MessageChannel-based messaging, and Datasette stored queries so teams can prototype or ship small custom tools that run next to private databases without exposing secrets or breaking the host page. The feature ties into the existing Datasette Agent workflow: apps can be created or edited using AI tools when Datasette Agent is installed, and the create-app prompt is explicitly designed to be fed to LLMs for code generation.

The implementation is also an example of AI-assisted development in practice. Willison credits prototypes and security evaluations done with Claude Opus 4.6, Codex Desktop, GPT-5.5 xhigh, Codex, and a brief window of testing with Claude Fable 5, which found a real attack vector that shaped the permission model.

What to watch

Watch for adoption of apps-set-csp and allowed_csp_origins in real deployments, and for early examples of full read-write apps built on top of Datasette stored queries. Also watch whether Datasette Agent-driven workflows for creating and editing apps become a common path for teams using the plugin.