| Server IP : 85.214.239.14 / Your IP : 3.145.102.72 Web Server : Apache/2.4.62 (Debian) System : Linux h2886529.stratoserver.net 4.9.0 #1 SMP Tue Jan 9 19:45:01 MSK 2024 x86_64 User : www-data ( 33) PHP Version : 7.4.18 Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, MySQL : OFF | cURL : OFF | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : OFF Directory : /usr/share/doc/nodejs/contributing/ |
Upload File : |
# Security Model Strategy A clear security model, with features like permissions and policy enforcement, is a [top technical priority](https://github.com/nodejs/node/blob/HEAD/doc/contributing/technical-priorities.md#permissionspoliciessecurity-model) of Node.js. ## High-level approach * Document the security model * Document threat models and current state of the art * Support experimentation on features like permissions and policies * Add a security component in Node.js certification covering the Node.js security model ### Document the security model The current security model for Node.js is not yet well documented. At a high level it is: * Node.js does not provide a sandbox, both the JavaScript and native code which is run is trusted to not be malicious. * The project works to help code running on top of Node.js to avoid making mistakes, but not doing so is not considered a vulnerability in Node.js. Just because you can build something vulnerable with the APIs does not mean there is a vulnerability in Node.js itself. The project has a goal to better document the security model and this section will be expanded when that happens. Once the security model is documented the project will work to add a security component in Node.js certification covering the Node.js security model. ### Document threat models and current state of the art Node.js is used in several different use cases and the threats may be different in each use case. The project should document the threat models and use that to help define the security model in the context of each of these use cases. This section will be expanded as the use case/threat models are defined. The initial list includes: * Server * Desktop application * Cli * Single executable application * CI/CD pipeline components ### Support experimentation on features like permissions The project is not currently planning to provide supported sandbox functionality, but wants to support experimentation on related features like permission enforcement. Features in this category should: * be opt-in, and additional overhead when not enabled must be low * limit change in core to just what is needed to enable experimentation