Skip to main content

One post tagged with "Deployment"

Hosting, origins, headers and the preview infrastructure.

View All Tags

Three ways to isolate a preview, and the Cloudflare wildcard trick

ยท 8 min read

When an in-browser IDE runs your dev server and shows you the result, the result has to be served from somewhere. The easy answer is the origin you already have: put the preview at /preview/5173/ on the IDE's own domain, let the Service Worker route by path, ship it.

That is what we did, and it is a security problem.

Same origin means the same cookie jar, the same localStorage, the same IndexedDB, the same OPFS, the same Cache Storage, the same Service Worker scope. Preview code, which includes every npm package the project installed and anything an AI assistant just generated, sits inside the IDE's origin. It can read the editor's session state, corrupt its persistence, and call its same-origin APIs. Previews are not isolated from the IDE, and they are not isolated from each other.

Fixing this properly took three attempts, and each one ran into a different piece of web platform trivia.