DEV Community: Luis Rodriguez

Themes, slots and AI edits for untrusted components

Luis Rodriguez — Thu, 01 Oct 2026 09:19:34 +0000

The first note was about running someone else's React component without letting it break, hang, or reach into the page. That covers the code itself. Real products that run user code usually go one step further: users customize a shared component library, and more and more often, an AI writes part of the code for them.

So I added three things to the playground: theme tokens, slots, and an AI edit panel. Each one comes with failure cases you can trigger, same as before. This note covers the design decisions behind them and the details that mattered most.

The rule: compose, don't edit

The first decision shaped everything else. Users can customize the component kit, but they can't change it. There's no forking a component or editing its source. Customization goes through two narrow doors:

Theme tokens: a handful of typed values (colors, radius, spacing, font scale).
Slots: named places inside a component where you can put your own content, like a card's header or a button's icon.

Narrow doors are easier to check. If users could edit kit source, every customization would be arbitrary code with access to the kit's internals. With tokens and slots, the kit decides what can vary, and everything else stays fixed.

Theme tokens instead of custom CSS

The obvious way to let people theme a component is to accept CSS. The problem is that CSS can do much more than change colors. background: url(...) makes a network request, position: fixed can cover the whole page, and a stray } can end one rule and start another.

So the theme panel accepts six tokens, each with a narrow format:

const hex = z.string().regex(/^#(?:[0-9a-f]{3}|[0-9a-f]{6})$/i)

export const ThemeOverrides = z
  .object({
    accent: hex,
    surface: hex,
    text: hex,
    radius: z.number().int().min(0).max(24),
    space: z.number().int().min(2).max(8),
    fontScale: z.number().min(0.8).max(1.4),
  })
  .partial()
  .strict()

A color must be a hex value, so red; background: url(https://evil.example/pixel.png) is rejected before it goes anywhere. .strict() rejects unknown tokens instead of silently dropping them, so a typo shows up as an error rather than a theme that mysteriously doesn't apply.

Some rules need the whole theme, not one value. Text on the surface color has to meet 4.5:1 contrast, so a theme can't make the kit unreadable. That check runs after the overrides are merged over the defaults.

Like everything else, the theme is checked twice. The host validates it to show issues next to the panel, and the sandbox checks it again before applying anything. Each token then becomes a CSS variable, set one at a time:

for (const [name, value] of Object.entries(themeToCssVars(theme))) {
  document.documentElement.style.setProperty(name, value)
}

setProperty sets one value. Even if something slipped past the schema, it couldn't add another declaration the way string concatenation into a stylesheet could. The kit's CSS reads only those variables, and derives borders, muted text and hover states from them with color-mix(). That keeps the theme to six tokens instead of twenty.

Slots, each with its own error boundary

Slots let users change a component's layout without touching its code:

<Card title="Team" slots={{ aside: <Badge tone="success">popular</Badge>, footer: <Button>Buy</Button> }}>
  …
</Card>

Slot content is user code, so it can throw. The playground already had an error boundary around the whole component, but if a slot failing took down the entire card, that would look the same as any other render error. So each slot gets its own small boundary. A slot that throws is replaced with a placeholder, and the rest of the card keeps rendering. The host shows a slot error that names which slot failed.

The kit is also read-only in code, not just by convention. User code receives a frozen object of frozen components, so ui.Button = MyButton throws a TypeError instead of quietly changing the kit for everything else on the page.

AI edits, without a server

The AI panel lets you describe a change ("add a subtitle prop") and get back an edited version of the component. I wanted it to stay a static site with no backend, and nothing that spends someone else's money. So it's bring-your-own-key: you paste your own OpenAI API key, and the request goes straight from the browser to OpenAI.

That makes two things worth protecting: the key, and the page from whatever the model sends back.

Keeping the key in one place

Memory only. The key lives in the AI panel's state. It isn't saved, isn't in the URL, and closing the panel forgets it.
One destination. The host page has its own Content Security Policy, with connect-src 'self' https://api.openai.com. Even if something on the page misbehaved, the key can't be sent anywhere else. script-src 'self' rules out injected scripts on the page that holds it.
Never near the sandbox. No message to the sandbox has a field that could carry it. A test enforces this as an architecture rule: it fails if the sandbox or messaging code ever imports the AI modules, or if the message protocol gains a field named like a key or token.
Least privilege. The panel recommends a restricted key (Responses: write, nothing else) with a hard spend limit, so a leaked key can only make model calls, up to a few dollars.

Treating the model's output as untrusted

The model's reply is just more untrusted code, so it gets the same treatment as anything typed by hand, plus a review step:

Strict shape. The request asks for JSON matching a schema ({ summary, code }), and the reply is validated with Zod anyway. Refusals, cut-off answers and wrong-shaped JSON each get a clear message instead of a crash.
Review mode. The proposal replaces the editor with a diff. Changed lines are marked, with counts, so it's obvious what you're looking at isn't your code yet.
Pre-check. The proposal is compiled and import-scanned without running it, so the review shows "would be blocked (import): 'axios' is not available" before you decide.
Accept means "put it in the editor". From there it goes through the normal pipeline: compile, scope, validate, sandbox. Accepting can't skip a single check.

To show that without needing a key, the panel has two canned responses. One is a reasonable edit. The other is what a compromised or confused model might return: it imports axios and adds a fetch that tries to send document.cookie somewhere. The pre-check flags the import during review, and if you accept it anyway, the import allowlist stops it and the sandbox's CSP would block the fetch.

The malicious demo response in review mode. The pre-check flags the import before anything runs.

Prompt injection deserves an honest note. Instructions hidden in a code comment could steer the model, and the prompt only asks it to ignore them. That isn't a defense on its own. What makes it acceptable here is that nothing the model returns is trusted: the worst a hijacked reply can do is propose code that you review and the sandbox contains.

Details that mattered

Freezing the kit isn't enough on its own. Compiled import * as ui goes through an interop helper, and for an object without an __esModule marker, that helper copies the exports into a new, writable object. With only a freeze, ui.Button = MyButton succeeds: user code patches the copy while the frozen original sits untouched, so the "read-only" kit looks editable. A non-enumerable __esModule flag makes the helper use the frozen object as-is, and the assignment throws.
Slot errors happen before "rendered". The sandbox reports success from an effect, after React commits the tree. But error boundaries catch during the commit itself, which runs before effects. Sent separately, a slot's error would arrive first and the "rendered" message right after would clear it. So slot errors from the first render are collected and sent along with "rendered", and errors that happen later (after a click, say) are sent on their own.
The model names in the docs and on the pricing page didn't match. One page listed one generation of models and another page a newer one, and I nearly hardcoded names from the stale one. The account's own limits page was the source of truth. The panel now also maps a "model not found" error to a readable message, in case names change again.
A spend limit looks like a rate limit. When the hard spend limit is reached, the API answers with HTTP 429, the same status as "too many requests". A generic 429 handler would say "wait a moment and try again", which would never work. The panel tells the two apart by the error code.
A diff above the editor was confusing. The first version showed the proposal as a box above the real code, and it was easy to read one as the other. Swapping the editor for the diff while reviewing fixed it: one code view at a time.

What this doesn't cover

The key is readable by the page that holds it. The CSP limits where it can be sent, but code running on the host page could still read it. That's why the panel pushes restricted keys with spend limits.
Themes are deliberately limited. Six tokens can't express everything a designer might want. That's the tradeoff for being able to validate every value.
Runtime behavior isn't reviewed. The pre-check only catches what's visible statically. A proposal that compiles cleanly can still misbehave when it runs, and it's the sandbox that contains that, not the review.

Try it

In the playground, the theme tab has presets and two theme examples that fail on purpose, the pricing card shows slots, and ✦ ai edit works with your own key or the two demo responses. The README lists every safeguard next to the example that triggers it.

Originally published at lrod.dev.

Running untrusted React components in the browser

Luis Rodriguez — Wed, 30 Sep 2026 02:49:11 +0000

Page builders, plugin systems and customizable dashboards all have the same problem somewhere in them: users write UI code, and your app has to run it. That code might be broken or it might be hostile, and either way the rest of the page has to keep working.

I built a small playground to work through that problem end to end. You write a React component in TSX, it compiles and renders live, and a gallery of examples tries to break it in nine different ways. This note walks through how it works, layer by layer, and what each layer does and doesn't protect against.

The source is on GitHub.

What can go wrong

Before choosing any tools, I listed what a user's component could do to the page hosting it:

Fail to compile. A syntax error or a half-typed line.
Import things it shouldn't. Anything from a network client to your app's internal modules.
Get the wrong data. Props that don't match what the component expects.
Throw. During render, or later from a click handler or a timer.
Hang. An infinite loop, or a regex that backtracks forever.
Reach out. Read the host's DOM, cookies or storage, or send data somewhere with fetch.

Each of these needs a different defense, and no single one covers them all. An error boundary doesn't stop a fetch, and a sandboxed iframe doesn't stop an infinite loop. So the playground is built as layers, each with one job:

Numbers match the sections below. Compiling happens in the host; everything that runs user code happens in the sandbox.

1. Compile in the browser

The code starts as TSX, which browsers can't run. I wanted the demo to be a static site with no server, so compiling had to happen in the page.

I used Sucrase. It strips TypeScript types and rewrites JSX, and it's small and fast because that's all it does. esbuild-wasm and Babel standalone can do more, but both are much bigger downloads, and a live preview doesn't need bundling or older-browser output.

The part that matters most for safety is Sucrase's imports transform. It rewrites every import into a require() call:

import { Card } from '@kit/ui'
// becomes
var _ui = require('@kit/ui')

That gives the runtime a single place where every dependency is requested, which the next layer uses.

Compiling runs in the host rather than the sandbox. It's a pure string-to-string transform, so it's safe to run there, and syntax errors still show up with a line and column even if the sandbox is down.

The tradeoff: Sucrase doesn't type-check. Type errors in user code are silently ignored, which is fine for a preview but worth knowing.

2. Scope what the code can import

The obvious approach is to block the dangerous modules. That list never ends. The playground does the opposite: user code gets a fixed set of modules (react, zod, and a tiny UI kit), and everything else doesn't exist.

This is checked twice. First, the host scans the compiled code for require('...') calls and rejects anything off the list before the code is sent anywhere. The user gets a clear message and nothing runs.

A static scan misses computed names like require(someVar), so the sandbox enforces the same list again at runtime. The code runs with a require that only knows about the allowed modules:

const require = (name: string) => {
  if (Object.hasOwn(modules, name)) return modules[name]
  throw new Error(`'${name}' is not available in this sandbox.`)
}

const run = new Function('require', 'module', 'exports', code)
run(require, module, exports)

Object.hasOwn matters there. A plain modules[name] lookup would also find inherited properties, so require('constructor') would return something.

One limit to be honest about: the allowlist covers modules, not globals. User code can still reach window, document and fetch without importing anything. Containing those is the job of layer 4.

3. Validate props against a contract

A component that gets the wrong props usually crashes somewhere deep inside, with an error that says nothing about the actual problem. So each module can export a contract alongside the component:

export const propsSchema = z.object({
  name: z.string().min(1),
  role: z.enum(['admin', 'member']),
})

export const exampleProps = { name: 'Ada', role: 'admin' }

export default function ProfileCard({ name, role }: z.infer<typeof propsSchema>) {
  // ...
}

Before every render, the props are checked against propsSchema. If they don't match, the component never runs, and the user sees a list of what's wrong instead of a stack trace:

props don't match propsSchema:
name: Too small: expected string to have >=1 characters
role: Invalid option: expected one of "admin"|"member"

The previous render stays on screen, so a typo in the props editor doesn't blank out the preview.

Two details here took some thought. The validation runs inside the sandbox, not the host, because the schema is itself user code, and user code only runs in the sandbox. And the check is duck-typed: anything with a safeParse method counts as a schema. An instanceof check would break the moment the schema came from a different copy of Zod.

4. Isolate it in a sandboxed iframe

Layers 1 to 3 handle mistakes. This is the layer that handles bad intent, and it's the one that's enforced by the browser rather than by my code.

Rendering happens in an iframe with sandbox="allow-scripts". What matters is what's missing: without allow-same-origin, the frame gets an opaque origin. As far as the browser is concerned, it's a different site from the host, so it can't read the host's DOM, cookies or localStorage. window.parent.document throws a SecurityError. The other flags that are left off also block forms, popups and navigating the top-level page.

On top of that, the sandbox document has a strict Content Security Policy:

default-src 'none';
script-src 'self' 'unsafe-eval';
connect-src 'none';
form-action 'none';
base-uri 'none'

connect-src 'none' is the important line: fetch, XHR and WebSocket all fail, so user code can't send anything anywhere. 'unsafe-eval' is needed because user code runs through new Function, and that's acceptable here because the whole document exists to run untrusted code.

The host and sandbox talk only through postMessage, and both sides treat every message as untrusted input:

Check the sender. The host ignores anything that isn't from its own iframe (event.source), and the sandbox ignores anything that isn't from its parent.
Validate the shape. Every message is parsed with a Zod schema on both sides, and error messages are length-capped.
Tag each render with an id. If a slow render from three edits ago reports back late, the host sees an old id and drops it. Without this, a stale result can overwrite a newer one.

Because the sandbox has an opaque origin, messages have to be sent with a target origin of '*'. That's fine only because nothing sensitive ever goes into them: just the user's own code and the render status.

5. Recover from crashes and hangs

The last layer assumes something got through and makes sure the page recovers.

Render errors are caught by an error boundary around the component. Errors outside render, like a throw in a click handler or a timer, never reach an error boundary, so the sandbox also listens for error and unhandledrejection on window.

Hangs are harder. Error boundaries can't help with while (true) {} because nothing is thrown, and a hung script can't report anything. I ended up with two mechanisms.

The first is a loop guard. Before the code is sent, the host parses it (with acorn) and rewrites every loop to check a timer on each iteration:

while (x) { body }
// becomes
{ const __t1 = performance.now(); while (x) { __loopGuard(__t1); body } }

After one second, __loopGuard throws, and the infinite loop becomes an ordinary render error. It works in every browser. It's also easy to get around if you're trying to, so it's a usability feature, not a security boundary.

The second is a watchdog, which catches everything else, like a regex that backtracks forever. The host pings the sandbox every second. If three seconds pass without a reply, the host throws the whole iframe away and mounts a fresh one: new document, new JavaScript realm. It deliberately doesn't resend the code that hung, or the new iframe would hang too.

The watchdog has a catch: it only works if the stuck iframe isn't blocking the host. Chromium runs sandboxed cross-origin frames in their own process, so the host keeps running and can pull the plug. Browsers that share a thread between the two freeze the whole tab until the loop guard fires. That's why the loop guard matters, even though the watchdog looks like the stronger tool.

Things that surprised me

A few bugs taught me more than the parts that worked the first time:

The sandbox couldn't load its own scripts. With an opaque origin, even the sandbox's own JavaScript files count as cross-origin, and module scripts are fetched with CORS. The iframe sat on "loading" until I served /assets/* with Access-Control-Allow-Origin: *. That's safe here because those files are public anyway.
An infinite loop hit the watchdog instead of the loop guard. React retries a render that throws before giving up, so the guard threw, React tried again, and the same loop ran for another second, then another. The fix was to make the guard "sticky": once it trips, it throws immediately until the next render.
"Rendered" was reported before anything rendered. I posted success right after calling root.render(), but rendering happens later. A component that crashed during render would briefly report success, then error. Now a small wrapper sends "rendered" from an effect, which only runs once React has actually committed the tree.

What this doesn't cover

Type-checking. Types are stripped, not checked, and nothing verifies that propsSchema matches the component's prop types.
CPU and memory limits. The watchdog recovers from hangs, but a component can still use a lot of memory or CPU before anything notices.
Side channels. Timing tricks and layout measurement aren't in scope.
The browser's own sandbox. Everything in layer 4 relies on the browser enforcing origins and CSP correctly, which is a reasonable bet but still a bet.

For production use, the next steps would be running the compiler in a Web Worker, type-checking where it matters, and serving the sandbox from a separate domain rather than relying only on the opaque origin.

Try it

The playground has a working example and one example per failure case, so you can watch each layer catch something. The source and README go into each decision in more detail.

Originally published at lrod.dev.

The Never-Ending Game of Whack-a-Mole: A Hilarious Take on JavaScript Frameworks

Luis Rodriguez — Mon, 15 May 2023 03:07:25 +0000

Let's face it, frameworks have made our lives easier and our code more efficient. But sometimes, it's good to take a step back and laugh at the absurdity of it all. So, without further ado, let's dive into the wild world of JavaScript frameworks.

Oh boy, where do I even begin with JavaScript frameworks? It seems like every day there's a new one popping up, promising to be the ultimate solution for all your front-end development woes. And let's be real, half of them are just fancy buzzwords slapped together in a way that sounds impressive but ultimately ends up being more confusing than helpful.

Don't get me wrong, I love a good framework as much as the next developer. But sometimes it feels like we're just creating more work for ourselves by constantly jumping from one to the next, trying to stay on top of the latest trends. It's like a never-ending game of whack-a-mole, except instead of moles, it's just different variations of React.

And let's not forget the joy of trying to integrate these frameworks with each other. It's like trying to fit a square peg into a round hole, except the peg is made of spaghetti code and the hole is a black hole of dependencies. You spend hours trying to get everything to work together, only to have it break again the moment you add a new feature.

But hey, at least we can all bond over our shared frustration, right? Maybe one day we'll all just give up and go back to plain old vanilla JavaScript. Or maybe we'll just keep creating new frameworks until the end of time. Who knows? All I know is that I need a drink after trying to figure out which version of Angular I should be using. Cheers to all my fellow JavaScript devs out there, may our code always compile and our dependencies never break.