Electron 43: Custom protocol hardening closes cross-origin backdoor

platform version release preview infographic

Production outage pattern: a renderer hits OOM, the crash report is useless, and your “safe” app:// protocol quietly behaves like an internal API reachable from any random webview. platform version release preview for Electron 43 is mostly about killing that footgun and giving you better memory forensics before the OOM killer (or your users) does it for you.

Custom protocol hardening: supportFetchAPI no longer implies “readable cross-origin”

You know the drill: register a custom scheme, flip supportFetchAPI: true, and suddenly half your app is “just fetch.” The nasty bit was never the syntax. The nasty bit was routing.

PR #51152 spells it out: subresource requests for registered custom protocols were reaching ElectronURLLoaderFactory via the renderer’s per-scheme factory bundle, bypassing Chromium’s CorsURLLoaderFactory. Translation: a cross-origin page could fetch() your scheme and read the body even when you didn’t set corsEnabled: true.

Electron 43 clamps this down: cross-origin mode: 'cors' gets rejected unless you explicitly opt in with corsEnabled: true. Cross-origin mode: 'no-cors' now returns an opaque response (body not script-readable) while still allowing things like <img> loads.

So what? Any app that treated a custom protocol as an internal RPC surface (common in desktop apps that grew “organically”) is about to discover whether it accidentally relied on cross-origin readability. Expect bug reports that look like “CORS broke in Electron” when it’s actually “you had a cross-origin data leak.”

Memory forensics: contentTracing.enableHeapProfiling()

When a renderer OOMs, the usual postmortem is a shrug and a screenshot. Electron 43 adds a better weapon: PR #50826 introduces contentTracing.enableHeapProfiling() backed by Chromium’s MemoryInfra.

You can now capture heap profiling data in traces instead of guessing whether the leak is JS objects, DOM, GPU resources, or “some native thing.”

Gotcha: the PR discussion calls out that Chromium didn’t have a clean stop mechanism for the heap profiling supervisor at the time; treat this as a targeted debug mode, not a default-on knob.

Window sizing behavior change: constraints enforced at creation time

PR #49906 fixes a surprisingly common UX papercut: minWidth/maxWidth (and friends) weren’t reliably enforced during BrowserWindow creation on Windows/Linux. Some WMs would “fix it later,” which means the window starts in the wrong place and reports the wrong size until it’s shown.

Electron 43 applies constraints at init and centers/positions after final size is known.

So what? If your first-render layout logic assumes the initial size equals the requested size, you may see new jank — but it’s your jank becoming visible, not Electron inventing it.

Desktop apps keep trying to masquerade as “web apps with nicer packaging.” Then a security review happens, and everyone realizes a custom scheme is effectively an internal origin with privileged data access.

The Electron team is paying down architectural debt caused by protocol handling living in a weird limbo between “Chromium network stack” and “Electron convenience API.” PR #51152 is the maintainers admitting: the correct mental model is Chromium’s model, and Electron should not be a CORS bypass machine.

On the ops side, heap profiling in tracing is a blunt acknowledgment that modern Electron apps die from memory behavior long before they die from missing features. Users don’t care that you added another notification option. They care that Slack/Discord/your app isn’t eating 2–4GB RSS after a week.

Test the preview build

Install the prerelease:

npm i -D electron@43.0.0-alpha.1

Or track Electron’s prerelease channel:

npm i -D electron@alpha

Red Flags (watch your logs and runtime behavior)

Protocol/CORS breakage: failed fetch/XHR to your custom scheme from cross-origin contexts; unexpected opaque responses on no-cors.
Security regressions you accidentally depended on: any code path that “worked” because it could read custom-scheme responses cross-origin. Fix it properly: use corsEnabled: true only where you mean it.
Tracing overhead / flakiness: if you enable heap profiling, validate trace capture in CI and on end-user machines; treat failures as expected until you harden the workflow.
Window geometry differences: initial window size/centering changes when width conflicts with minWidth/maxWidth; snapshot tests that assert pixel-perfect bounds will start screaming.