security consideration for shared dependencies

[hosseinalipour]

I'd like to discuss a potential security consideration regarding shared dependencies during module loading.

Consider the standard ESM behavior where different modules importing the same URL receive the same instance (e.g., App imports B, A imports C, C imports B – all get the same B instance).

The potential risk scenario is:

1. Dependency C loads as part of the module graph resolution.
2. During its own initialization (top-level code execution), C modifies the shared instance of B.
3. Later, when the App's code runs, it receives this already-altered version of B, potentially before the App has had a chance to apply its own safeguards like Object.freeze(B).

This "load-time alteration" could lead to unexpected behavior or security vulnerabilities if C acts maliciously or incorrectly.

While Deno's permission system is crucial for limiting the impact of compromised code, and freezing modules after import helps, neither seems to directly prevent this initial modification of a shared module instance during the graph loading phase itself by an earlier-loading dependency.

Is this scenario something the Deno team has considered? What is the recommended approach or Deno's perspective on mitigating this specific risk inherent in shared mutable module instances during load time? Have there been considerations regarding mechanisms, perhaps leveraging loader hooks or specific APIs, that could allow applications to intercept the module instantiation or resolution process? Such a capability could enable preemptive application of security policies (like immediate freezing or wrapping modules in hardened proxies) before a shared instance is provided to potentially untrusted dependencies during graph loading. While ESM's static nature differs significantly from CommonJS, the underlying need for finer control during loading echoes discussions seen in other environments like Node.js (though mechanisms like the now-deprecated require.extensions are not directly comparable given ESM architecture).