WebAssembly Security
What is WebAssembly Security?
WebAssembly SecurityThe security model of WebAssembly — capability-based sandbox, no ambient access to syscalls, structured control flow — plus the practical risks of memory-unsafe languages compiled to Wasm and untrusted Wasm running outside the browser.
WebAssembly (Wasm) is a portable, binary, stack-based VM with a deliberately conservative security model: linear memory is isolated from the host, control flow is structured (no arbitrary jumps), all imports are explicit, and there is no ambient I/O — a Wasm module can only do what its host (browser, runtime, WASI implementation) hands it as imported functions. Inside the browser this complements the same-origin policy and CSP; outside it (Cloudflare Workers, Fastly Compute, edge runtimes, Envoy filters, plugin systems), Wasm enables running untrusted code from third parties with capability-based controls. Security work focuses on (1) memory safety inside the module — buffer overflows in Wasm-compiled C/C++/Rust still exist and have already led to JIT-spray-style attacks on browser engines; (2) WASI capability scoping — restricting filesystem, network, and clock access per module; (3) supply-chain integrity of Wasm artifacts (component model, signed component-registry releases); and (4) side-channel resilience against Spectre, since Wasm can be a delivery vector for speculation primitives.
● Examples
- 01
An edge runtime gives each tenant's Wasm module a capability-scoped filesystem rooted at `/tenant/<id>` and no network sockets at all.
- 02
A vulnerability in a JPEG decoder compiled to Wasm allows out-of-bounds reads inside the module, but the host's linear-memory isolation prevents it from escaping into other processes.
● Frequently asked questions
What is WebAssembly Security?
The security model of WebAssembly — capability-based sandbox, no ambient access to syscalls, structured control flow — plus the practical risks of memory-unsafe languages compiled to Wasm and untrusted Wasm running outside the browser. It belongs to the Application Security category of cybersecurity.
What does WebAssembly Security mean?
The security model of WebAssembly — capability-based sandbox, no ambient access to syscalls, structured control flow — plus the practical risks of memory-unsafe languages compiled to Wasm and untrusted Wasm running outside the browser.
How does WebAssembly Security work?
WebAssembly (Wasm) is a portable, binary, stack-based VM with a deliberately conservative security model: linear memory is isolated from the host, control flow is structured (no arbitrary jumps), all imports are explicit, and there is no ambient I/O — a Wasm module can only do what its host (browser, runtime, WASI implementation) hands it as imported functions. Inside the browser this complements the same-origin policy and CSP; outside it (Cloudflare Workers, Fastly Compute, edge runtimes, Envoy filters, plugin systems), Wasm enables running untrusted code from third parties with capability-based controls. Security work focuses on (1) memory safety inside the module — buffer overflows in Wasm-compiled C/C++/Rust still exist and have already led to JIT-spray-style attacks on browser engines; (2) WASI capability scoping — restricting filesystem, network, and clock access per module; (3) supply-chain integrity of Wasm artifacts (component model, signed component-registry releases); and (4) side-channel resilience against Spectre, since Wasm can be a delivery vector for speculation primitives.
How do you defend against WebAssembly Security?
Defences for WebAssembly Security typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for WebAssembly Security?
Common alternative names include: Wasm security, WASI security.
● Related terms
- appsec№ 145
Browser Sandbox
An OS-level isolation layer that confines a browser's renderer and helper processes so that compromised web code cannot read the file system or other applications.
- appsec№ 744
Memory Safety
Memory safety is the property that a program never reads, writes, or executes memory it has not legitimately allocated, preventing entire classes of vulnerabilities.
- appsec№ 745
Memory-Safe Languages
Memory-safe languages such as Rust, Go, Swift, Java, and C# prevent the spatial and temporal memory errors that drive most exploitable vulnerabilities in C and C++.
- appsec№ 1064
Rust Security Properties
Rust enforces memory and thread safety at compile time through ownership, borrowing, and lifetimes, eliminating common UB classes such as use-after-free and data races without a garbage collector.
- appsec№ 237
Content Security Policy (CSP)
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
- appsec№ 1164
Site Isolation
A Chromium security architecture that places documents from different sites into separate operating-system processes so a compromised renderer cannot read cross-site data.