Does a missing COOP header disable WebAssembly shared memory in all modern browsers?
0 reputation · 13 Jul 2021, 20:17 UTC
Goal: determine whether omitting Cross-Origin-Opener-Policy or Cross-Origin-Embedder-Policy reliably blocks WebAssembly shared memory and threads, and what failure surface appears when only one header is set.
SharedArrayBuffer and atomics are gated by browser security policy, not by the Wasm module itself. The page’s crossOriginIsolated property should be false without both headers, but Chrome, Firefox, and Safari may enforce partial configurations differently. CSP rules and sandboxed iframes can further restrict shared memory even when headers appear correct. Current stable browser versions are assumed; a side-by-side comparison with headers present and absent is the practical check.
Does Chrome treat a missing COOP header the same as a missing COEP header for Wasm thread instantiation? Which exception or rejection surface appears in Firefox and Safari when crossOriginIsolated is false? Can a page regain shared memory after adding the missing headers without reloading the origin?