Secure Plugin Sandboxes in Modern Web Editors: VS Code, Atom, and Figma

Due to length, this article is split into a series that uses a web‑app plugin architecture for illustration.

1. Introduction

As web technologies mature, large‑scale applications such as Alibaba Cloud consoles become increasingly complex, making maintenance, release, and cost control harder. Micro‑frontend architectures emerged to address these challenges, and this article uses that trend as a backdrop to discuss similar issues in modern web editors and design tools.

2. The Rise and Fall of Modern Text Editors

After Microsoft acquired GitHub in 2018, Atom was frequently mocked as a lagging competitor. VS Code has become the de‑facto editor for front‑end engineers, outperforming Atom in both performance and plugin ecosystem—VS Code surpassed 10,000 plugins, while Atom remains around 8,000. The adoption of heavyweight protocols like LSP/DAP further cemented VS Code’s dominance.

Discussions about Atom’s decline often cite performance, which is largely tied to its overly permissive plugin architecture. Atom exposed many UI hooks to plugins, resulting in inconsistent plugin quality and security risks. Core UI components such as FileTree, Tab bar, and Settings Views are implemented as plugins. VS Code, by contrast, runs plugins in a Node.js environment with a far more closed UI API.

While VS Code’s closed model improves stability, it limits deep UI customisation, prompting some developers to hack the editor—modifying CSS for background images or swapping FFmpeg libraries to enable audio/video playback. These hacks can corrupt the installation, forcing users to reinstall.

3. Beyond Editors – Figma

Figma, an online collaborative UI design tool, recently launched a JavaScript‑based plugin system, lowering the barrier for developers and designers to extend the platform.

4. How Figma's Plugin System Works

Figma plugins are built with a TypeScript + React stack and bundled via Webpack. The directory structure looks like this:

.
├── README.md
├── figma.d.ts
├── manifest.json
├── package-lock.json
├── package.json
├── src
│   ├── code.ts
│   ├── logo.svg
│   ├── ui.css
│   ├── ui.html
│   └── ui.tsx
├── tsconfig.json
└── webpack.config.js

The manifest.json defines the entry points:

{
  "name": "React Sample",
  "id": "738168449509241862",
  "api": "1.0.0",
  "main": "dist/code.js",
  "ui": "dist/ui.html"
}

Figma separates the plugin into main (runtime logic) and ui (HTML UI). Both are loaded inside isolated iframes, preventing CSS leakage and protecting the host application.

Figma’s documentation explains that the main runs in a minimal JavaScript environment on the main thread, with restricted access to browser globals, while the ui is a single HTML fragment rendered in a popup.

Initially, Figma sandboxed plugins using iframes, which forced all API calls to be async via postMessage. This approach proved unfriendly for designers and introduced performance overhead for large documents.

To improve performance, Figma moved execution back to the main thread but introduced a custom sandbox based on the stage‑2 Realm proposal, which isolates third‑party code by creating a separate global object.

Example of using Realm:

let g = window; // outer global
let r = new Realm(); // root realm

let f = r.evaluate("(function() { return 17 })");

f() === 17 // true
Reflect.getPrototypeOf(f) === g.Function.prototype // false
Reflect.getPrototypeOf(f) === r.globalThis.Function.prototype // true

Developers can also achieve similar isolation with with and Proxy patterns, forming a whitelist of safe APIs.

const whitelist = {
  window: undefined,
  document: undefined,
  console: window.console,
};

const scopeProxy = new Proxy(whitelist, {
  get(target, prop) {
    return prop in target ? target[prop] : undefined;
  }
});

with (scopeProxy) {
  eval("console.log(document.write)"); // Cannot read property 'write' of undefined!
  eval("console.log('hello')"); // hello
}

Further, a safe logging factory can be created inside a realm to prevent prototype‑chain leaks:

const safeLogFactory = realm.evaluate(`
  (function safeLogFactory(unsafeLog) {
    return function safeLog(...args) {
      unsafeLog(...args);
    }
  })
`);

const safeLog = safeLogFactory(console.log);

realm.evaluate(`log("Hello outside world!")`, { log: safeLog });

Figma also retains the original iframe option, allowing plugins to create their own iframes and communicate via postMessage.

1. JavaScript Sandbox

Sandboxing remains a hot topic. Simple iframe sandbox attributes provide isolation, while advanced approaches use with, Realm, Proxy, or embed a separate JavaScript engine like Duktape (compiled to WebAssembly) to execute third‑party code safely.

Web Workers have also been used to run DOM diff calculations off the main thread, with results sent back for rendering. Projects like preact‑worker‑demo, react‑worker‑dom, and Google’s AMP Worker‑DOM explore this pattern.

2. CSS Scope

For style isolation, Figma’s iframe approach offers perfect separation at a performance cost. Modern front‑end tooling can use CSS Modules (hash‑based class names) or Web Components with Shadow DOM, which prevent external styles from leaking into plugin UI and vice‑versa.

6. Conclusion

This article surveyed the challenges faced by large‑scale web applications that support third‑party plugins, from the contentious iframe model to modern sandboxing techniques such as Realm, Web Workers, and Shadow DOM. Each solution carries trade‑offs, and as web applications grow more complex, standardized plugin architectures will become increasingly important. The next installment will explore the KAITIAN IDE’s plugin system, covering JavaScript sandboxing, CSS isolation, and Worker‑based rendering.