doc: add Node.js Threat Model

Co-authored-by: Michael Dawson <[email protected]>
Co-authored-by: Facundo Tuesca <[email protected]>
Co-authored-by: Ulises Gascon <[email protected]>
Co-authored-by: Thomas Gentilhomme <[email protected]>

SECURITY.md

@@ -53,6 +53,86 @@ Here is the security disclosure policy for Node.js
   the release process above to ensure that the disclosure is handled in a
   consistent manner.
 
+## What does Node.js trust/not trust
+
+Being able to cause a negative outcome in a way that requires control of the
+elements that are trusted by Node.js is not considered a vulnerability in
+Node.js.
+
+Being able to cause the following through control of the elements that Node.js
+does not trust is considered a vulnerability:
+
+* Disclosure or loss of integrity or confidentiality of data protected through
+the correct use of Node.js APIs.
+* The unavailability of the runtime, including the unbounded degradation of its
+performance.
+
+If Node.js loads configuration files or runs code by default (without a
+specific request from the user), and this is not documented, it is considered a
+vulnerability.
+Vulnerabilities related to this case may be fixed by a documentation update.
+
+**Node.js does NOT trust**
+
+1. The data from network connections that are created through the use of Node.js
+APIs and which is transformed/validated by Node.js before being passed to the
+application. This includes:
+  * HTTP APIs (all flavors) client and server APIs.
+  * DNS APIs.
+2. Consumers of data protected through the use of Node.js APIs (for example
+people who have access to data encrypted through the Node.js crypto apis).
+3. The file content or other IO that is opened for reading or writing by the use
+of Node.js APIs (ex: stdin, stdout, stderr). In other words, Node.js doesn’t
+interpret buffers unless explicitly set by the user.
+
+**Node.js trusts everything else**. As some examples this includes:
+
+1. The developers and infrastructure that runs it.
+2. The operating system that Node.js is running under and its configuration,
+along with anything under control of the operating system.
+3. The code it is asked to run including JavaScript and native code, even if
+said code is dynamically loaded. The code run inherits all the privileges of
+the execution user.
+4. Inputs provided to it by the code it is asked to run, as it is the
+responsibility of the application to perform the required input validations.
+5. Any connection used for inspector (debugger protocol) regardless of being
+opened by command line options or Node.js APIs, and regardless of the remote
+end being on the local machine or remote.
+6. The file system when requiring a module.
+See https://nodejs.org/api/modules.html#all-together.
+
+Any unexpected behavior from the data manipulation from Node.js Internal
+functions are considered a vulnerability.
+
+In addition to addressing vulnerabilities based on the above, the project works
+to avoid APIs and internal implementations that make it “easy” for application
+code to use the APIs incorrectly in a way that results in vulnerabilities within
+the application code itself. While we don’t consider those vulnerabilities in
+Node.js itself and will not necessarily issue a CVE we do want them to be
+reported privately to Node.js first.
+We often choose to work to improve our APIs based on those reports and issue
+fixes either in regular or security releases depending on how much of a risk to
+the community they pose.
+
+### Some examples of applying this thread model include:
+
+#### Malicious Third-Party Modules (CWE-1357)
+
+* Code is trusted by Node.js, therefore any scenario that requires a malicious
+third-party module cannot result in a vulnerability in Node.js.
+
+#### Prototype Pollution Attacks (CWE-1321)
+
+* Node.js trusts the inputs provided to it by application code.
+It is up to the application to sanitize appropriately, therefore any scenario
+that requires control over user input is not considered a vulnerability.
+
+#### Uncontrolled Search Path Element (CWE-427)
+
+* Node.js trusts the file system in the environment accessible to it.
+Therefore, it is not a vulnerability if it accesses/loads files from any path
+that is accessible to it.
+
 ## Receiving security updates
 
 Security notifications will be distributed via the following methods.