Suggestion: add standard methods to limit APIs dependencies can use

[io4]

I believe it might help to allow packages to set limits on which APIs can be accessed by the dependencies. This way, packages that do not need access to abusable resources such as FS access, networking and native bindings (those can access everything else) can be restricted from using them, reducing the impact in the event of packages whose job is mostly data processing (most body processors, utilities such as lodash) being compromised.

I believe the implementation does not need to be granular, and that with simply restricting access of a dependency (and all its childs).

While this is probably not the ideal way to implement sandboxing, I believe that some sandboxing method would be helpful.

[boneskull]

I think this is probably out-of-scope

[wesleytodd]

I agree that this is out of scope for this group.

I believe Ryan Dahl talked about this in his Deno presentation with flags to allow process access to certain api's, interesting stuff.

[io4]

I believe this has a overlap area with the scope, because being able to use dependencies without a fault in one of them causing a massive failure improves the maintainability of projects in my opinion.

Having to check if the dependencies are safe for usage is a maintainer problem.

Think, for example, of all the maintainers who, for example, got affected by the event-stream problem and had to immediately take action of replacing the dependency.

This feature would give the maintainer a reasonable time to make the change, without having anyone's security at risk.

[mcollina]

This would be useful, but it's mainly a node core feature. As such, it is out of scope.

Most of the discussion is happening in nodejs/node#22112 and nodejs/security-wg#457.

I'm closing this issue to reduce noise, but please join the discussion on the two links I posted above.