Wasm Security Model

Every piece of memory a WebAssembly module can touch lives inside its own linear memory, a contiguous, bounds-checked array of bytes that the runtime allocates and that grows only in whole 64KiB pages via explicit memory.grow calls. Every load and store instruction is bounds-checked against the current memory size before it executes, so a buggy or malicious module cannot read or write arbitrary host process memory the way a native buffer overflow can corrupt adjacent heap data; an out-of-bounds access simply traps and halts execution. Combined with the fact that Wasm has no instructions capable of directly manipulating a raw machine pointer or jumping to an arbitrary code address, this makes memory-safety violations inside the sandbox contained: a compromised Wasm module can corrupt its own linear memory, but it cannot use that corruption to escape into the host's address space without a bug in the host embedding itself.

Unlike native machine code, where a corrupted return address or function pointer can redirect execution to attacker-controlled bytes (classic ROP/JOP exploitation), WebAssembly has no raw jump instructions at all; control flow is expressed only through structured constructs, if/else, loop, block, and br/br_if for branching within them, and call/call_indirect for invocation, all validated at load time to reference only valid, well-typed targets. Indirect calls through a function table are checked against the callee's declared type signature at call time, so even if an attacker could corrupt a table index, the runtime would trap rather than execute a mismatched-signature function, which closes off an entire class of control-flow-hijacking exploits that plague native code. This validation happens once, eagerly, when the module is loaded, which is also why a hostile module can be rejected outright before a single instruction executes if it fails to type-check.

A Wasm module has zero ambient authority: it cannot open a file, make a network connection, or read an environment variable unless the host explicitly imports a function granting that capability. WASI formalizes this as capability-based security, most visibly through preopened directory handles: a host running a module with Wasmtime's --dir=./data flag grants that module a file descriptor scoped only to the ./data subtree, and the module can never construct a path like ../../etc/passwd to escape it, because it never receives a capability referencing anything outside the preopen in the first place, not because of a runtime string check on '..' segments. This is a fundamentally different security posture from a traditional process, which by default inherits broad ambient access to the filesystem and network and must be actively restricted after the fact with something like seccomp or a container boundary; Wasm/WASI instead starts from zero access and grants capabilities explicitly, one handle at a time.