1. Why does WebAssembly “look dangerous” in terms of security?

Make an intuitive judgment first:

Features	Security Risks
Close to native speed	Similar to native code
Explicit memory	Easy to cross boundaries
Can be compiled	Difficult to statically analyze
Often from third parties	Supply chain risks

👉 If Wasm can access the system at will, browser security will crash directly

So:

Wasm was designed from the beginning to be "caged native code"

2. The overall security position of Wasm in Chrome

操作系统
  ↑
Chrome OS Sandbox
  ↑
Renderer Process
  ↑
V8 Wasm Engine
  ↑
WebAssembly Module

👉 Wasm does not have higher permissions 👉 It is just an execution engine in Renderer

3. The first line of defense: process-level isolation (Chrome)

1️⃣ Where is Wasm running?

• Renderer Process
• Same level as JS
• Protected by Site Isolation

bank.com Wasm → Renderer A
evil.com Wasm → Renderer B

Even if Wasm is compromised:

• Cannot cross site
• Can't access OS

2️⃣OS-level sandbox

Renderer process:

• Cannot read or write arbitrary files
• Cannot call system API
• Unable to execute system commands

👉 Wasm has no concept of "system call"

4. The second line of defense: Wasm’s language-level security model ⭐⭐⭐⭐⭐

This is the core security point of Wasm.

1️⃣ There is no “arbitrary pointer”

int* p = (int*)0xdeadbeef; // ❌ Wasm 中不存在

Wasm：

• Only Linear Memory
• address = offset

2️⃣ Linear memory model

Linear Memory
 ├── 0x0000
 ├── ...
 ├── 0x10000

Linear-memory accesses must respect overall memory bounds:

• Out-of-range accesses trap; checks or guard pages can enforce the semantics.
• Adjacent objects within the region can still be overwritten; C/C++ buffer bugs and use-after-free do not vanish.

👉 Host isolation is not object-level application memory safety. 👉 Valid instructions cannot arbitrarily access Renderer memory or the JS Heap; engine bugs are a separate risk.

3️⃣ Non-executable data (W^X)

• Wasm memory ≠ executable
• Separation of Code Space and Data Space

👉 Prevent:

• shellcode injection
• JIT spraying

4️⃣ Module verification (Validation)

Wasm before execution:

• Verify bytecode first
• Control flow is legal
• correct type
• Stack balancing

非法模块 → 拒绝加载

5. The third line of defense: V8 Wasm engine

1️⃣ Compilation process

Wasm Binary
  ↓
Decoder & Validator
  ↓
Liftoff（baseline compiler）
  ↓
TurboFan（优化编译）

security policy

• Compile quickly first
• Re-security optimization
• Can be rolled back at any time

2️⃣ Preserve linear-memory bounds semantics

Even after optimization:

• Out-of-bounds accesses must preserve trap semantics.
• Proven-safe accesses may eliminate redundant checks or use guard pages; the semantics do not mandate an explicit check on every access.

3️⃣ Interaction with JS is “controlled”

Wasm cannot take the initiative:

• Access DOM
• Make network request
• Call system API

Only:

imported_function()

👉 JS is Capability Broker

6. The fourth line of defense: Capability-based Security

Wasm itself has no abilities, the abilities come from the host

Example

const wasm = new WebAssembly.Instance(module, {
  env: {
    log: console.log
  }
})

Wasm can only:

• Call log
• Cannot call alert
• Cannot access document

👉 This is one of the strongest security models

7. Wasm vs JS: Who is more dangerous?

Dimension	JS	Wasm
Memory model	No arbitrary-address syntax; engine bugs remain possible	Isolated linear memory without object-level safety; engine bugs remain possible
Execution permissions	Restricted by browser and host APIs	Restricted by host imports and browser policies
Performance	Depends on workloads and optimization	Suitable for some compute tasks; measure it
Attack surface	JS engine, DOM and host APIs	Wasm engine, imports and application logic

Language names do not establish overall safety. Wasm protects host boundaries; applications still need safe languages, input checks and resource management.

Official WebAssembly memory safety documentation.

8. What can Wasm attack?What can't be attacked?

❌ Can’t

• Bypass the same origin policy
• Access Cookies
• Manipulating the DOM
• Send a request directly
• Tuning system API

⚠️ Possible risks

• DoS (infinite loop)
• Specter side channel (mitigated)
• Engine implementation vulnerabilities; do not describe them as rare without a defined dataset.

9. Wasm + CSP security strategy

Content-Security-Policy:
  script-src 'self';
  object-src 'none';

⚠️ Wasm by:

• script-src
• wasm-unsafe-eval (new)

script-src 'self' 'wasm-unsafe-eval';

👉 Default is stricter

10. Real attack perspective (very important)

Attack Chain (Extremely Hard)

恶意 Wasm
 ↓
V8 Wasm JIT bug
 ↓
突破 Wasm sandbox
 ↓
突破 Renderer sandbox
 ↓
OS

👉 Chrome security goals:

Make this chain almost unfeasible

11. The ultimate answer to "WebAssembly security model"

Browser WebAssembly is constrained by the same-origin policy, renderer sandbox and host capabilities. Validation and linear-memory bounds provide isolation without object-level safety. Imports grant host capabilities; application bugs, resource exhaustion and engine vulnerabilities remain relevant.