Sandboxing confines code to a memory-safe execution environment and exposes host resources only through specific capabilities granted by the runtime. A Wasm module can print to standard output when permitted, but cannot otherwise access native operating-system interfaces or memory. section 1.2.4
A capability-based sandbox provides:
- Explicit host interaction: the runtime grants narrow capabilities such as standard output instead of exposing all system calls. section 1.2.4
- Component isolation: separately running modules reduce the chance that a compromised component can affect the rest of an application. section 1.2.4
- Lightweight containment: Wasm provides built-in isolation with minimal overhead compared with containers and virtual machines. section 1.3
Application plugins
A host application can execute a plugin as an isolated Wasm module and grant only the capabilities it needs. This limits the damage a vulnerable plugin could cause while preserving portability across hosts. section 1.3
Figure 1.6 A native (traditional) application security model versus Wasm’s capability-based security model
Compare the traditional model, where native applications access operating-system calls and memory broadly, with Wasm’s capability-based security model. section 1.2.4
Sandboxing is especially valuable in cloud environments, where a supply-chain vulnerability can otherwise spread through shared resources. It does not remove every trade-off: Wasm still has limited multithreading support, and its package ecosystem includes incompatible components. section 1.2.4 section 1.3
