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. Pertenece a la categoría de Seguridad de aplicaciones en ciberseguridad.

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.

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.

Las defensas contra WebAssembly Security combinan habitualmente controles técnicos y prácticas operativas, como se detalla en la definición.

Nombres alternativos comunes: Wasm security, WASI security.