Check where the module came from, what it imports from the host, what files or network access you would grant, which source libraries were compiled into it, and what host limits you will enforce. A module declares everything it can call at load time, which makes review practical.
Why modules deserve a review
WebAssembly modules run in a sandbox, and the WebAssembly security documentation says they must declare all accessible functions and their types at load time. A module cannot escape the sandbox without going through the APIs it imports. That is a strong starting point, and it gives a reviewer something concrete: the list of imports.
It is not a substitute for review. The same documentation notes that code reuse attacks, race conditions and side channels are not addressed by the semantics, and a vulnerable library inside still behaves as written.
Six steps
1. Establish provenance. Who built it, from which source and with which toolchain? Prefer modules with published source and reproducible builds. If you cannot find the source, you cannot review the dependencies inside.
2. Read the imports. List the host functions the module asks for. Each import is a door. An image filter that imports network functions is a question to ask.
3. Decide the capabilities to grant. Under WASI, Wasmtime documents a capability model where an application can only access files and directories it has been given. Grant specific directories, read only if possible, and no network unless needed. On Cloudflare Workers, WASI support is described as experimental with only some syscalls implemented, so check the platform page before assuming a feature.
4. Inventory what is compiled in. Find the source libraries and versions behind the binary. A .wasm file hides them from manifest scanners. Ask the vendor for an SBOM, or build from source and keep your own.
5. Set host limits. Limit memory, execution time and the number of instances. The sandbox keeps the module away from the host, but it does not stop a module from using the resources you give it.
6. Plan updates. A fix in an upstream library does nothing for a binary that is already built. Know how you will learn of a rebuild and how you will roll it out.
What to record
| Field | Example question |
|---|---|
| Origin and version | Can we fetch it again and compare hashes? |
| Imports | Does each import match the module's stated purpose? |
| Granted capabilities | Are they the minimum? |
| Source dependencies | Are any on a vulnerable version? |
| Resource limits | What happens at the limit? |
| Update owner | Who rebuilds, and how often? |
Red flags
- No source and no build instructions.
- Imports that do not match the purpose.
- Requests for broad file system or network access.
- No process for security fixes.
- A size far larger than expected for the function, which can hint at bundled extras. Cloudflare notes that Workers using WebAssembly are typically larger than an equivalent JavaScript Worker, and that larger Workers can take longer to start, so size is also a performance concern.
Treat plugins like dependencies
If your product loads Wasm plugins from users, add signature checks, per plugin permissions and an easy way to disable one. Log what each plugin touches.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how exploitability depends on how a component is used. A module's imports and granted access tell you the same story.
Quick check
Is a signed module automatically safe?
No. A signature shows who published it and that it was not altered. It does not tell you whether the code inside is secure.
What is the fastest review step?
Read the imports. They list what the module can ask the host to do, so mismatches stand out quickly.
Safeguard's SBOM and dependency scanning cover the source repositories behind your modules, and its policies and gates can enforce review rules. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
