Security

44.1 What the Sandbox Guarantees

Memory isolation: a module can't access memory outside its linear memory/GC objects. No raw host pointers.

Control-flow integrity: structured control flow, typed indirect calls, a protected call stack (return addresses not in linear memory).

No ambient capabilities: no I/O unless imported.

44.2 What It Does NOT Guarantee

Memory safety inside linear memory: C/C++ bugs (buffer overflows, use-after-free) still corrupt the program's own data. They can't escape the sandbox, but can subvert program logic (e.g., overwriting function-pointer table indices, data, the shadow stack). Use memory-safe languages (Rust) or hardening (stack canaries, ASan in testing, CFI options).

Side channels: Spectre-class attacks. Engines mitigate (site isolation, timer coarsening, masking). Cross-origin isolation is required for SharedArrayBuffer.

Host API misuse: vulnerabilities often live in host import functions (unchecked pointers/lengths from the guest).

Supply chain: malicious Wasm packages/plugins. Verify sources, pin versions, and sign artifacts (Sigstore/cosign, wasm-sign).

44.3 Web Security Considerations

Content Security Policy: compiling Wasm requires script-src 'wasm-unsafe-eval' (preferred over 'unsafe-eval').

Serve .wasm from trusted origins with correct MIME types. Use Subresource Integrity (SRI) for scripts loading Wasm.

Never trust data coming back from Wasm modules supplied by third parties (validate it like any untrusted input).

44.4 Server/Plugin Security

Grant minimal WASI capabilities (specific directories, no network unless needed). Set fuel/epoch limits, memory limits, and timeouts. Use one instance per request/tenant.

Validate all guest-provided pointers and lengths in host functions. Keep runtimes patched (runtime CVEs do occur). Consider defense-in-depth (process isolation + Wasm).