WebAssembly Security
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.
● 示例
- 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.
● 常见问题
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. 它属于网络安全的 应用安全 分类。
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.
WebAssembly Security 是如何工作的?
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.
如何防御 WebAssembly Security?
针对 WebAssembly Security 的防御通常结合技术控制与运营实践,详见上方完整定义。
WebAssembly Security 还有哪些其他名称?
常见的别称包括: Wasm security, WASI security。
● 相关术语
- appsec№ 145
浏览器沙箱
操作系统层的隔离机制,限制浏览器的渲染进程和辅助进程,防止被攻陷的网页代码读取文件系统或其他应用。
- appsec№ 744
内存安全
内存安全指程序绝不读取、写入或执行未合法分配的内存,从而消除整类漏洞的属性。
- appsec№ 745
内存安全语言
Rust、Go、Swift、Java、C# 等内存安全语言可在源头消除导致 C/C++ 大多数可利用漏洞的空间与时间型内存错误。
- appsec№ 1064
Rust 安全特性
Rust 通过所有权、借用与生命周期在编译期强制内存与线程安全,在不依赖垃圾回收的前提下消除 UAF 与数据竞争等典型未定义行为。
- appsec№ 237
内容安全策略 (CSP)
一种 HTTP 响应头,告诉浏览器允许加载哪些来源的脚本、样式、框架等内容,从而限制 XSS 与数据注入攻击的影响。
- appsec№ 1164
站点隔离
Chromium 的一种安全架构,将不同站点的文档放入独立的操作系统进程,使被攻陷的渲染进程无法读取跨站点数据。