Simon Willison Builds Sandbox with Dynamic CSP Allowlist

An iframe protected by Content Security Policy often becomes a dead end for developers: the blocked request appears in the console, and the only solution is to manually modify the CSP header and reload. On May 13, Simon Willison released an experimental tool that completely changes this workflow, intercepting errors before they disappear into the void and giving users the option to allowlist the blocked domain in that same moment.

The practical result is striking: you can load an arbitrary application inside an iframe with `default-src 'none'`, attempt a call to `https://api.inaturalist.org` (or any other domain), receive a modal asking if you want to allow that origin, accept it, and watch the page reload with the expanded CSP. All without touching a configuration file.

How the mechanism works

The key lies in a custom version of `fetch()` injected into the protected iframe. When a request is blocked by CSP, that `fetch()` captures the error and communicates it to the parent document via `postMessage`. The parent, which has full access to the application state, displays the confirmation dialog. If the user accepts, the domain is added to an allowlist persisted in memory and the page refreshes with a new CSP that includes that origin in `connect-src`.

This pattern builds on earlier research that Willison documented in early April, where he explored how to controllably escape from a CSP-protected iframe to communicate with the parent document. The tool published this week is the practical application of that experiment.

You can test it directly at tools.simonwillison.net/csp-allow, which features an HTML editor in the left panel and a preview on the right, with buttons to reset the example, clear the allowlist, and refresh the preview.

Why this matters for code execution environments

This type of sandbox with dynamic CSP has direct applications in browser-based code execution tools, preview environments like CodePen, or systems where an AI agent generates HTML/JS code that runs in isolation. The classic problem in these contexts is that the developer building the sandbox doesn't know in advance what external APIs the generated code will need.

With this approach, the allowlist stops being an upfront design decision and becomes a runtime decision by the user. The sandbox remains strict by default; it only opens when the user explicitly authorizes it, domain by domain.

Simon Willison's original post doesn't mention integration with any particular LLM, though the tool fits naturally into workflows where Claude or another model generates web applications that then run in immediate preview.

Limitations the experiment itself acknowledges

The approach has some rough edges. The allowlist lives in the parent document's memory, so it doesn't persist between sessions unless additional storage is implemented. Moreover, the interception mechanism depends on the custom `fetch()` covering all request types that CSP can block: images, scripts, workers, or WebSockets have different blocking paths that a simple `fetch()` wrapper doesn't necessarily capture.

It's an experiment, not a production-ready library. Willison presents it with that honesty, which is precisely what makes it useful as a starting point for anyone wanting to build something more robust on this foundation.

---

Editor's take: The approach is elegant because it doesn't weaken CSP by default, but makes it negotiable with the user rather than something to ignore. For teams building preview environments for code generated by agents, it's worth at least prototyping for evaluation.