contextBridge.exposeInMainWorld: prototype loss and origin‑agnostic access

Direct Answers

1. Prototype preservation: No mechanism preserves the prototype chain through contextBridge.exposeInMainWorld. The bridge uses the structured clone algorithm, which intentionally strips prototypes, getters/setters, and non-enumerable properties. Class instances arrive as plain objects; instanceof checks fail. This is by design since Electron 12 introduced contextBridge.
2. Per-origin/per-window access control: No Electron API or configuration enforces origin-based permissions on exposed APIs. Any renderer in the same session can invoke them. You must implement manual origin checks inside each exposed function using window.location.origin or document.origin.
3. Version history and pending fixes: The prototype-loss behavior debuted with contextBridge in Electron 12 (replacing the older contextBridge-less preload approach). Electron 20+ added exposeInIsolatedWorld for isolated contexts but did not change structured-clone semantics or add origin gating. No pending Electron fixes or RFCs aim to add automatic prototype preservation or origin-based permissions; maintainers consider manual origin checks the correct pattern.

Confirmed Facts vs. Likely Explanations

Confirmed (documented/observable)	Likely Explanation (inferred)
Structured clone strips prototypes, getters/setters, non-enumerable properties	Security boundary: prevents prototype pollution and ensures only serializable data crosses contexts
Class instances become plain objects; instanceof fails	Intentional design — functions and symbols cannot be cloned
No built-in origin gating; any renderer in session can call exposed APIs	Electron's threat model treats the renderer process as the trust boundary, not individual origins
exposeInIsolatedWorld (Electron 20+) changes target world only	Does not mitigate prototype loss or add permissions

Practical Workarounds for Your Case

Preserve Method Access (Not Prototype)

// preload.js
const { contextBridge } = require('electron');
class ApiService {
  constructor() { this.state = 'ready'; }
  doWork(payload) { return `processed: ${payload}`; }
  getState() { return this.state; }
}
const instance = new ApiService();

// Expose bound methods — retains this but not prototype
contextBridge.exposeInMainWorld('api', {
  doWork: instance.doWork.bind(instance),
  getState: instance.getState.bind(instance)
});

Renderer receives { doWork: f, getState: f } — plain functions bound to the preload instance. No instanceof ApiService, but methods work.

Enforce Origin Check (Defense-in-Depth)

// preload.js
const ALLOWED_ORIGIN = 'https://your-app.example.com';

contextBridge.exposeInMainWorld('api', {
  doWork(payload) {
    // This runs in the renderer context — window is the renderer's window
    if (window.location.origin !== ALLOWED_ORIGIN) {
      throw new Error('Origin not allowed');
    }
    return instance.doWork(payload);
  }
});

Caveat: A compromised renderer can spoof window.location.origin. Treat this as defense-in-depth, not a security boundary.

Alternative: RPC-Style Handler

// preload.js
const methods = {
  doWork(payload) { return `processed: ${payload}`; },
  getState() { return instance.state; }
};

contextBridge.exposeInMainWorld('api', {
  invoke(method, ...args) {
    if (window.location.origin !== ALLOWED_ORIGIN) throw new Error('Origin not allowed');
    if (!(method in methods)) throw new Error(`Unknown method: ${method}`);
    return methods[method](...args);
  }
});

Single entry point, easier to maintain, centralizes origin check.

Verification Steps (Run Once)

1. Create a minimal Electron app with the preload above.
2. In renderer: console.log(typeof window.api.doWork, window.api instanceof ApiService, Object.getPrototypeOf(window.api)) — observe function, false, Object.prototype.
3. Navigate renderer to file://, http://localhost, https://example.com and call window.api.doWork('test') — confirm any origin can invoke without the manual check.

One Diagnostic Detail Needed

Are you exposing a stateful singleton (methods mutate internal state) or a stateless service (methods are pure or read-only)? This changes whether bound-method exposure suffices or you need a factory/reconstruction pattern.