doc: specify to use primordials when coding

[RedYetiDev]

For security reasons, the use of primordials is important when editing the NodeJS core, and this should be reflected in the documentation on editing NodeJS.

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[anonrig]

There is an ongoing process to investigate and remove primordials. I don't think we should encourage using it.

[RedYetiDev]

There is an ongoing process to investigate and remove primordials. I don't think we should encourage using it.

If primordials are removed, wouldn't that threaten the security of Node.js? AFAIK primordials are needed to prevent prototype pollution and similar.

[aduh95]

AFAIK primordials are needed to prevent prototype pollution and similar.

Primordials are a tool to workaround (some) prototype pollution, but it's not the only one. (e.g. native code is typically not subject to prototype pollution without using primordials)

wouldn't that threaten the security of Node.js?

Not necessarily, it depends what "removing primordials" mean. I think it's fallacious to think of primordials as a security feature, a code using primordials can still be subject to prototype pollution, and not all prototype pollution would fall under the threat model of Node.js. It's more useful to think of it as a tool that improves the reliability of Node.js internals.

[joyeecheung]

If primordials are removed, wouldn't that threaten the security of Node.js?

Primordials are not a security mechanism, under the threat model of Node.js, see discussions in nodejs/TSC#1158.

Node.js trusts everything else. As some examples this includes:

The code it is asked to run including JavaScript and native code, even if said code is dynamically loaded, e.g. all dependencies installed from the npm registry. The code run inherits all the privileges of the execution user.

They are only a UX enhancement mechanism (for the internals not crash badly when user code modify the prototype incorrectly, e.g. if you throw an error, you don't want the Node.js error handler to go crazy because someone modifies some prototype method it uses and it'll be a lot harder to fix said error).

If an attacker already has the ability to run arbitrary code in the process, they can just e.g. require("child_process").spawn or process.dlopen() or new require("inspector").Session() to do whatever they want. Polluting the prototype would be one of the least cost-effective ways to do an exploit.