WebAssembly core module to JavaScript host export visibility and accidental public surface

Direct Answer

No. The current core WebAssembly specification provides no internal linkage, private symbols, or runtime access-control mechanism that prevents an entry from appearing in the export section. Host visibility is exactly the set of functions, memories, tables, and globals named in that section. An unexported definition is unreachable by name, but it is not private in a language-level sense.

Confirmed Facts vs. Likely Explanation

Confirmed: Core wasm has no concept of source-level visibility. Once compiled, the module format exposes only what the export section lists. There is no later runtime permission model that can restrict access to an exported item.

Likely explanation for accidental surface: When internal helpers leak to JavaScript, the cause is almost always a build or binding layer emitting broad default exports. Compilers and linkers may export everything unless an explicit allowlist is enforced. This is a toolchain configuration issue, not a gap in the core specification.

Component Model status: The Component Model and WIT add declarative interface contracts and a canonical ABI around a component. They can keep core-module internals behind a typed boundary, but they do not introduce private exports into core wasm itself. A component can still expose more than its WIT world if built incorrectly.

Steps for This Case

1. Audit the final artifact, not the source. In Node.js, list the exact exports:

const bytes = await readFile('module.wasm');
const mod = await WebAssembly.compile(bytes);
console.log(WebAssembly.Module.exports(mod));

1. Inspect the binary with WABT or wasm-tools:

wasm-objdump -x -j Export module.wasm
# or
wasm-tools print module.wasm

1. Check exported tables and globals for indirect references. An unexported function can still be reachable if it appears in an exported table or funcref global. After instantiation, inspect table contents:

const table = instance.exports.my_table;
console.log(table.get(0)); // may reveal unexported function references

1. For components, enumerate the component's imports and exports with your host toolchain and compare them against the intended WIT world.

Assumptions and Uncertainty

Toolchain defaults vary by version and flags; the commands above assume a standard Node.js runtime and WABT/wasm-tools availability. Component Model resource ownership and drop semantics remain version-sensitive, so verify against your specific toolchain version. If a specific compiler or binding generator is emitting unexpected exports, sharing the tool name and flags would refine the allowlist configuration, though it does not change the core answer.