WASM Components Security:
Capability-Based Security Only Works if You Configure the Capabilities.

The Capability Model in WASI

WASI (WebAssembly System Interface) defines a capability-based security model where WASM modules start with no ambient authority — they cannot access the file system, network, environment variables, or any other host resource unless the host explicitly passes them a capability handle for that resource. This is fundamentally different from POSIX where processes inherit ambient authority from their user identity.

The WASM Component Model builds on this by composing multiple WASM modules through typed interfaces (WIT - WASM Interface Types). Components can only interact with each other and the host through explicitly defined interfaces, and the host controls which capabilities are passed to which components. In theory, this provides strong isolation: a compromised component can only abuse capabilities it was explicitly granted.

Over-Granted Capabilities

The path of least resistance when running WASM components is to grant them everything they might need — full filesystem access, all environment variables, unrestricted outbound networking. This is equivalent to running a container as root with all capabilities enabled: the security model is technically present but provides no actual constraint. Most WASM runtime quickstart guides and documentation examples show maximally permissive configurations for simplicity.

The --env-inherit flag is particularly dangerous: it passes every environment variable from the host process to the WASM component — including any credentials, tokens, or secrets that happen to be set in the host environment. A WASM component with --env-inherit in a CI or production environment can read credentials that were never intended for it.

Host Interface Attacks

The host interface — the functions that WASM modules call to interact with the runtime — is a trust boundary that must be implemented correctly in every WASM runtime. Bugs in the host interface implementation can allow WASM modules to escape the sandbox, read host memory outside their allocated linear memory, or trigger undefined behaviour in the runtime. WASM runtimes (Wasmtime, WASMer, V8's WASM engine) have all had CVEs related to host-boundary safety — typically in areas like table access bounds checking, memory64 handling, and SIMD operations.

The confused deputy problem applies to WASM host functions: if a host function trusts the WASM module's claimed identity or context without verification, a malicious component can invoke the host function in a way that causes the host to perform actions beyond what the component's capabilities should allow — for example, claiming to be a different component to access a resource it was not granted.

WebAssembly Component Supply Chain

The WebAssembly component ecosystem is young but growing rapidly. Component registries are being established for sharing reusable WASM components — similar to npm for JavaScript or crates.io for Rust. This introduces supply chain risks that are familiar from other ecosystems but with a WASM-specific twist: components are compiled, making static analysis harder. Malicious WASM bytecode is not as easy to inspect as malicious JavaScript — you cannot simply read the source to identify suspicious behaviour.

A compromised WASM component can use any capabilities it is granted: read files in the allowed directory tree, make HTTP requests to the granted network endpoints, and access environment variables it was given. The capability model limits the blast radius of a compromised component, but only if capabilities were granted precisely — not if the component received broad permissions.

Side Channels in WASM

WASM's security model does not include protection against side-channel attacks. Spectre-class vulnerabilities apply to WASM in browser contexts — research has demonstrated that WASM can be used to implement high-resolution timers and exploit speculative execution to read host memory outside the WASM sandbox. Browser vendors have mitigated many of these attacks through timer precision reduction and site isolation, but server-side WASM runtimes may not have equivalent mitigations.

In multi-tenant WASM deployments — where multiple untrusted components from different tenants run in the same process — side-channel isolation is a meaningful concern. A malicious tenant component can potentially infer information about other tenants' data through cache timing attacks and other microarchitectural side channels.

Securing WASM Component Deployments

1. Apply minimum required capabilities: Audit every capability granted to each WASM component. Use the most restrictive path preopen instead of root, grant only the environment variables the component requires by name, and restrict network access to specific IP:port combinations where possible.
2. Never use --env-inherit in production: Explicitly list the environment variables each component needs. Never use inheritance flags that pass all host environment variables to the component.
3. Pin WASM components to verified digest hashes: When using third-party WASM components, pin to immutable content-addressed references. Verify component integrity with signed digests from component registries that support signing.
4. Use process isolation for untrusted components: Run untrusted WASM components in separate processes rather than the same process as trusted components. Process isolation provides a much stronger security boundary than WASM's intra-process sandbox.
5. Use production-grade WASM runtimes with active security maintenance: Prefer Wasmtime or other Bytecode Alliance runtimes with documented security response processes for production deployments. Monitor CVE feeds for your chosen runtime.
6. Apply network segmentation for WASM services: Even though WASM's capability model limits which network endpoints a component can connect to, network-level controls provide defense in depth. Apply egress filtering at the network level for WASM workloads that handle sensitive data.