The Sandbox Problem
By design, Wasm is a pure computation engine. Inside its sandbox, it can perform arithmetic and manipulate memory extremely fast, but it cannot interact with the outside world. It cannot open a file, make a network request, read an environment variable, or even check the system clock. This is intentional — the sandbox is what makes Wasm safe — but it makes Wasm useless as a standalone server technology.
In the browser, JavaScript acts as the bridge, giving Wasm access to browser APIs like the DOM, fetch, and localStorage. But on a server, there is no browser and no JavaScript host. Something else must fill that role.
Enter WASI: The WebAssembly System Interface
The WebAssembly System Interface (WASI) is a standardized set of APIs that allow Wasm modules to interact with the host operating system in a controlled, capability-based way.
Think of WASI as a security checkpoint at the border of the sandbox. The Wasm module inside the sandbox submits a request: "I need to read the file at /data/input.jpg." The WASI runtime acts as the border agent: it checks whether the module was granted access to that specific directory when it was launched. If yes, it performs the operation on the host OS and passes the result back into the sandbox. If no, the request is denied — the module never even sees the host filesystem.
This model is called capability-based security. Instead of a module having broad OS permissions (like a typical Linux process), it only has access to the specific resources explicitly handed to it at startup. This is fundamentally more secure than the POSIX model that containers rely on.
WASI Versions: Preview 1 and Preview 2
WASI is still evolving. WASI Preview 1 (the original) provided basic POSIX-like syscalls: file I/O, clocks, random numbers, and standard I/O. Most current tooling targets Preview 1.
WASI Preview 2 (ratified in 2024) is a major redesign built on the Component Model — a standard for how Wasm modules can be composed together, share types, and call each other's functions safely. Preview 2 introduces the WIT (Wasm Interface Type) format for defining interfaces, enabling language-agnostic interoperability between Wasm components. This is the foundation for building complex systems out of composable Wasm pieces.
Interviewers often ask: "How does WASI differ from a container's syscall interface?" The key answer: WASI uses capability-based security — a module has zero access by default and must be explicitly granted specific resources at launch. A container process, by contrast, inherits broad OS permissions and relies on seccomp/AppArmor deny lists to restrict access. Wasm's allow-list model is architecturally more secure.