Wasm for Plugins and Sandboxing

Analogy categoryAnalogies

Why Wasm Is a Natural Plugin Sandbox

A WebAssembly module executes entirely inside its own linear memory, with every load and store instruction bounds-checked by the runtime, so a buggy or malicious plugin cannot read or write arbitrary host process memory the way a native dynamic library loaded with dlopen or LoadLibrary could. Because a module has zero ambient access to the filesystem, network, or host memory unless something is explicitly imported, the default state of any embedded Wasm plugin is 'can compute, but can observe or affect nothing outside itself.'

🏏

Cricket analogy: A player warming up in the nets is physically fenced off from the main pitch, unable to affect the live match no matter how hard they hit the ball, just as a Wasm module can't touch host memory outside its own sandbox.

Host Embedding and the Import/Export Boundary

A host application embeds a runtime like Wasmtime or Wasmer and uses a Linker to explicitly decide which host functions a given plugin module is allowed to call — a logging callback, a specific read-only data query, or nothing at all beyond pure computation. This means the host, not the plugin author, defines the ceiling of what's possible; a plugin cannot request more capability than the host chooses to expose through that linker at instantiation time.

🏏

Cricket analogy: A ground curator decides exactly which practice facilities a visiting team may use, and the visitors have no way to request more than what's granted, mirroring host-defined import grants.

rust

use wasmtime::*;

fn main() -> Result<()> {
    let engine = Engine::default();
    let module = Module::from_file(&engine, "plugin.wasm")?;

    let mut linker: Linker<()> = Linker::new(&engine);
    // Only expose a single, narrow logging capability -- nothing else.
    linker.func_wrap("env", "host_log", |msg_ptr: i32, msg_len: i32| {
        println!("[plugin log] ptr={msg_ptr} len={msg_len}");
    })?;

    let mut store = Store::new(&engine, ());
    store.set_fuel(10_000)?; // cap runaway execution

    let instance = linker.instantiate(&mut store, &module)?;
    let run = instance.get_typed_func::<(), i32>(&mut store, "run")?;
    let result = run.call(&mut store, ())?;
    println!("plugin returned: {result}");
    Ok(())
}

Resource Limits and Fault Isolation

Runtimes let a host cap fuel — an instruction-count budget consumed as the plugin executes — along with the number of memory pages a module can grow to and wall-clock execution time, so a runaway or infinite-looping plugin can be interrupted cleanly rather than hanging the host thread indefinitely. When a module traps, whether from an out-of-bounds memory access, a checked integer overflow, or an explicit unreachable instruction, only that instance unwinds; unlike a native plugin segfault, the host process itself keeps running unaffected.

🏏

Cricket analogy: A bowler is limited to a fixed number of overs per spell, and if they're pulled mid-over for tactical reasons, the match simply continues with a new bowler — the team isn't derailed.

This isolation model is already in production use: Shopify Functions runs merchant-authored checkout logic as sandboxed Wasm, Figma's plugin architecture has evolved toward Wasm-based isolation, and Envoy proxy's WASM filters let operators extend request handling with third-party code without recompiling the proxy or trusting that code with full process access.

What Sandboxing Does Not Cover

Memory and syscall isolation don't automatically protect against every risk: a plugin without a fuel cap can still exhaust CPU by looping forever, timing side channels can leak information even across a memory-isolated boundary, and a plugin can freely abuse whatever capabilities the host does grant it — if a host hands over an unrestricted network-fetch import, the sandbox does nothing to stop that plugin from exfiltrating data through it. Sandboxing the runtime is necessary but not sufficient; the host's own capability grants have to be kept minimal for the model to actually hold.

🏏

Cricket analogy: Fencing off the practice nets stops a player from wandering onto the main pitch, but it does nothing to stop them misusing the bowling machine they were legitimately given access to.

The most common way to accidentally defeat Wasm's entire sandboxing model is convenience: granting a plugin a single broad host function like 'do_http_request(url)' with no allowlist, or a 'read_any_file(path)' import, hands back exactly the ambient authority the sandbox was designed to remove.

Wasm's bounds-checked linear memory prevents a plugin from reading or writing arbitrary host process memory, unlike native dynamic libraries.
Hosts use a Linker to explicitly grant only the specific host functions a plugin needs — the host defines the ceiling, not the plugin.
Fuel limits, memory page caps, and execution timeouts let a host interrupt runaway plugins cleanly without hanging the process.
A Wasm trap unwinds just that plugin instance; unlike a native segfault, the host process itself keeps running.
Production examples include Shopify Functions, Figma's plugin sandbox, and Envoy's WASM filters.
Sandboxing the runtime doesn't stop timing side channels or abuse of capabilities the host itself grants.
Granting even one overly broad host import (like unrestricted network or filesystem access) defeats the entire isolation model.