Skip to content

Latest commit

 

History

History
62 lines (46 loc) · 2.16 KB

security-model-strategy.md

File metadata and controls

62 lines (46 loc) · 2.16 KB
Raw

Security Model Strategy

A clear security model, with features like permissions and policy enforcement, is a top technical priority 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