Safeguard
Research•

What is WebAssembly and how does its security model work?

WebAssembly is a compact bytecode that runs in a sandbox in browsers and beyond. It limits what code can touch, but bugs inside a module still matter.

Safeguard Security Team
4 min read

WebAssembly, or Wasm, is a compact binary instruction format that runs in a sandboxed virtual machine, first in web browsers and now in other places too. You compile languages such as C, C++ or Rust to it. The sandbox limits what a module can access, but memory bugs inside a module can still be exploited.

What is it, in plain terms?

Wasm is a portable compilation target. Instead of shipping source or machine code for one processor, you ship a binary that any compliant runtime can validate and run at near native speed. The W3C publishes the core specification, and webassembly.org describes the project.

It is not a language you usually write by hand. It sits beside JavaScript in the browser, not instead of it. JavaScript loads the module and calls its functions, and the module can call back through functions that JavaScript provides.

How does the sandbox work?

The MDN documentation lays out the concepts. Four ideas explain most of the security model.

Validation. A runtime validates a module before running it. Malformed or type-incorrect code is rejected.

Linear memory. A module sees one contiguous block of memory it owns. It cannot read or write memory outside that block, including the browser's own memory.

Imports. A module has no ambient access to files, the network or the DOM. It can only use capabilities the host passes in as imports. Give it nothing and it can only compute.

Structured control flow. Control flow is limited to well-formed jumps, and function calls are checked, which prevents classic return address overwrites from redirecting execution to arbitrary code.

Does the sandbox make Wasm safe?

It makes the host safer from the module. It does not make the module correct. If you compile a C program with a buffer overflow, the overflow still happens inside the module's linear memory. An attacker may corrupt data in the module, change its behaviour or trick it into misusing the imports you gave it.

So an attack goes through whatever you exposed. If a module can call an import that writes files, a bug in the module may lead to files written. Keep imports minimal.

What about outside the browser?

Wasm runtimes are used on servers and in plugin systems because the sandbox is attractive for running third party code. The same principles apply. Grant capabilities one at a time, set limits for memory and run time, and treat the runtime as software you must patch, since runtime bugs can break the sandbox.

A constructed example

A web app compiles an image resizer written in C to Wasm so users can resize pictures in the browser. A crafted image triggers a heap overflow in the C code. The attacker cannot read the user's cookies or open network connections from the module, because it has no such imports. The worst result is a corrupted output or a crash in that module. Had the developer passed in a general purpose callback to the page's scripting environment, the overflow could have been steered into calling it. The lesson is to expose narrow functions, not broad ones.

Where do supply chain risks appear?

A Wasm module is built from source and dependencies like any other software. A vulnerable C library compiled into the module remains vulnerable. Keep an inventory of what went into each build, scan the source dependencies and rebuild when advisories appear. Safeguard's dependency scanning and SBOM generation apply to the source projects that produce Wasm, though the compiled output itself is a binary you still need to track as an artifact.

How to check or apply this

  1. List every import you pass to a module and justify each one.
  2. Prefer memory-safe source languages for new modules.
  3. Scan the source dependencies before compiling.
  4. Keep the runtime or browser updated.
  5. Set resource limits when running untrusted modules outside the browser.
  6. Fuzz the module's exported functions with malformed input.

Quick check

Can Wasm access my files by default?

No. A module has only the capabilities its host provides as imports.

Does Wasm prevent buffer overflows?

No. It stops them from escaping the module's own memory, but the module itself can still be corrupted.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.