WebAssembly Hardening Articles

Security-side WASM (auth filters, policy engines, MCP plugins) must be sub-millisecond to deploy at request rate. Pre-compilation and snapshotting get you there.

WASM lets you ship logic to constrained devices without firmware updates. The runtime, the trust model, and the OTA pipeline all need careful design.

Plugin systems built on WASM have a recurring shape. Threat-modeling that shape catches the structural mistakes before deployment.

WASM threading via SharedArrayBuffer re-opens Spectre-class timing attacks. Cross-origin isolation, per-tenant memory isolation, and atomics hygiene are required before enabling threads.

Edge runtimes execute untrusted customer code in shared processes. The hardening contract is the platform's, but the customer code's behavior decides the blast radius.

WASM plugins run inline in the data path. A misconfigured plugin can exhaust memory, leak tenant data, or crash the proxy. The defaults need explicit caps.

ngx_wasm_module brings the proxy-wasm protocol to NGINX. Plugin authoring is similar to Envoy, but the worker model and hardening surface differ.

WASM is the easy case for reproducibility — no dynamic linking, no runtime variance. Most teams still ship non-reproducible builds. The fix is small.

WASI HTTP servers are a clean platform-neutral pattern. The hardening is at the application layer — body limits, header allowlists, response shaping, and panic semantics.

Preview 2 replaces Preview 1's coarse imports with explicit, scoped, capability-passing interfaces. The security story is the actual reason to migrate.

wasi:sockets/tcp and wasi:sockets/udp give WASM modules network access. The capability model is fine-grained — most embedders use it as a coarse on/off switch.

Running AI inference inside WASM is a new deployment pattern with novel isolation properties. The threat model differs from GPU-served inference.

When you compose multiple components, every wire is a capability decision. The security story of a composed application lives in the WIT between components.

Databases are growing WASM extension points. The threat model spans both WASM-runtime escape and database-internal lateral access — different from container UDFs.

Running many tenants' WASM modules in one runtime is the hard case. Per-tenant fairness, isolation guarantees, and the failure modes that violate both.

WASM modules ride OCI registries the same as containers. The supply-chain hygiene story is the same — and most orgs do not apply it to .wasm artifacts.

WASM on Kubernetes via runwasi and containerd shims runs alongside containers but with a different escape surface, different RBAC implications, and different supply-chain controls.

Scanning .wasm artifacts is different from scanning containers — no rootfs, no package manager. The dependency graph is in the bytecode.

Wasmtime's defaults are friendly, not safe. Untrusted modules need explicit limits on CPU, memory, syscall surface, and filesystem access.

Wazero is the pure-Go WASM runtime used by Tetragon, Cilium, k6, Trivy, and dapr. The defaults are friendly; production deployments need explicit caps.