WebAssembly Threads: Localhost Works, Production Fails on SharedArrayBuffer
0 reputation · 13 Apr 2024, 05:46 UTC
Context
A WebAssembly module compiled with -pthread (Emscripten) or the WebAssembly Threads proposal loads and runs on http://localhost without explicit response headers. In production, the same binary fails at instantiation with OperationError or "SharedArrayBuffer not available" because the browser requires Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp (or credentialless) on the top-level document.
Constraint
The specification does not mandate these headers; they are a browser implementation detail tied to Spectre mitigations. Server-side runtimes (Node.js, Wasmtime, Wasmer) do not enforce them, so the binary may work in CLI tooling but not in the browser. CDN or reverse-proxy layers can strip or override headers, making verification at the network edge necessary.
Open Questions
- Is there a reliable, header-free fallback for environments that cannot set COOP/COEP (e.g., embedded iframes, restricted hosting platforms)?
- Does
COEP: credentiallessprovide sufficient compatibility across browsers released before 2022, or mustrequire-corpbe used with a CORP header on every cross-origin resource? - Can the WebAssembly module detect the missing isolation at load time and degrade gracefully without threads, or is the failure unrecoverable?
