One of the problems that you did not raise is that the module may try to connect directly to your database or to other services on your internal network. This can be prevented by setting passwords that the module cannot find so easily.
1. Restrict access to disk
This project was presented at NodeConf last year. It tries to restrict access to the file system in the exact situation that you are describing.
https://github.com/yahoo/fs-lock
"The purpose of this module is to help you download third-party modules, and you need to limit their access."
It sounds more like Jeffrey's suggestion made in the comments in response to Plato.
(If you want to take a closer look at OS call binding, this hook project may come up with a few ideas. Although in its current form it only wraps the callback function, it may inspire what needs to be done and how to do it. An example used.)
2. Analysis of the flow of confidential data
If you are concerned only with data theft (not a file system or database access), you can focus your problems:
You should be most worried about packets that transmit sensitive data. Presumably, some data about your web service will be presented to the public in any case!
Most packages will not have access to the full stack of your application, but only to the bits of data that you pass to them. If a packet is transmitted only with a small amount of confidential data and never misses the rest of the data, it may not be able to do anything malicious with the data it receives. (For example, if you transfer all your usernames to one package for processing and all your addresses to another package, it is much less than if you transfer all your usernames, addresses and credit card numbers to the same package!)
Define sensitive data in your application and pay attention to what functions they transmit.
3. Perform an effective code review
You may not need to go to Github to read the code. The vast majority of packages provide all of the source code in the installation folder inside node_modules . (There are several packages that provide binary files, but they are naturally more difficult to verify.)
If you really want to test the code yourself, there may be ways to reduce the amount of work:
To protect your application, you do not need to read the entire source code of all the packages in your project. You only need to look at those functions that are actually being called.
You can read the code by reading it, or using a text debugger or a GUI debugger . (Of course, you should look at the branch, where different inputs can call different parts of the module.)
Set breakpoints when you call a module that you do not trust, so you can go through the called code and see what it does. You can conclude that only a small part of the module is used, so only this code needs to be checked.
While the trace stream should cover issues with sensitive data at runtime, to check file access or database access, we should also look at the initialization code of each module that is required and all the calls (including require s) that are made from there.
4. Other measures
It might be wise to block the version number of each package in package.json so that you do not accidentally install a new version of the package until you decide what you need.
You can use social factors to build confidence in the package. Check the respectability of the author. Who is he and for whom does he work? Does the reputation of the author and his employers have a reputation? In the same way, who uses his project? If the package is very popular and used by industry giants, it is likely that others have already reviewed the code.
You might want to visit github and enable notifications for all the top-level modules you use by “viewing” the repository. This will tell you if any vulnerabilities in the package will be detected in the future.