Skip to content

Latest commit

 

History

History
97 lines (61 loc) · 5.77 KB

Security.md

File metadata and controls

97 lines (61 loc) · 5.77 KB
Raw

Security Policies and Procedures

This document outlines security procedures and general policies for the Express project.

Reporting a Bug

The Express team and community take all security bugs in Express seriously. Thank you for improving the security of Express. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions.

Report security bugs by emailing the lead maintainer in the Readme.md file.

To ensure the timely response to your report, please ensure that the entirety of the report is contained within the email body and not solely behind a web link or an attachment.

The lead maintainer will acknowledge your email within 48 hours, and will send a more detailed response within 48 hours indicating the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.

Report security bugs in third-party modules to the person or team maintaining the module.

Disclosure Policy

When the security team receives a security bug report, they will assign it to a primary handler. This person will coordinate the fix and release process, involving the following steps:

  • Confirm the problem and determine the affected versions.
  • Audit code to find any potential similar problems.
  • Prepare fixes for all releases still under maintenance. These fixes will be released as fast as possible to npm.

The Express Threat Model

The Express threat model delineates the trusted elements within the framework, such as the underlying operating system or the runtime. Vulnerabilities necessitating the compromise of these trusted elements lie outside the scope of the Node.js threat model.

For a vulnerability to be considered, it must adhere to the context of the Express threat model. This implies that it cannot assume the compromise of a trusted element, such as the operating system.

Elements Express Does NOT Trust:

  1. Data received from the remote end of inbound or sent to remote outbound network connections, which are accepted through the use of Express API and transformed/validated by Express before being passed to the application.

In simpler terms, if the data passing through Express to/from the application can initiate actions beyond those documented for the API, it likely signifies a security vulnerability. Examples of unwanted actions include polluting globals, causing an unrecoverable crash, or any other unexpected side effects jeopardizing confidentiality, integrity, or availability.

Elements Express Trusts:

  1. Developers and infrastructure responsible for running it.
  2. The operating system and JavaScript runtime Express operates under, including its configuration and anything within the control of the operating system.
  3. The code it executes, comprising JavaScript and native code, even if dynamically loaded, such as dependencies installed from npm or similar repositories.
  4. The resources it accesses, such as files, network connections, and other system resources, as long as they are accessed through the documented API.
  5. The privileges of the execution user are inherited by the code it runs.
  6. Inputs provided by the code it runs, as it is the application's responsibility to conduct necessary input validations, e.g., input to JSON.parse().

Examples of Vulnerabilities

Examples of vulnerabilities can be found in the Express Security Updates.

Examples of Non-Vulnerabilities

Malicious Third-Party Modules (CWE-1357)

  • Code trusted by Express implies that any scenario requiring a malicious third-party module does not result in a vulnerability in Express. For instance, if an application uses a vulnerable third-party module susceptible to a denial of service attack, it is not considered a vulnerability in Express.

Prototype Pollution Attacks (CWE-1321)

  • Express trusts the inputs provided by application code. Hence, scenarios necessitating control over user input are not considered vulnerabilities unless Express itself fails to sanitize the input properly.

Uncontrolled Search Path Element (CWE-427)

  • Express trusts the runtime environment accessible to it. Therefore, accessing/loading files from any accessible path is not a vulnerability. For example, misconfigurations with express.static() are not considered vulnerabilities. Additional information.

External Control of System or Configuration Setting (CWE-15)

  • If Express automatically loads a configuration from the environment, any modification to that environment does not constitute a vulnerability. For example, tampering with the NODE_ENV environment variable, causing Express to behave in dev mode instead of production mode, is not considered a vulnerability. Additional information.

Uncontrolled Resource Consumption (CWE-400) on Outbound Connections

  • Express being asked to perform an action impacting the runtime's performance or causing resource exhaustion due to user application code is not a vulnerability.

Vulnerabilities Affecting JavaScript Runtime

  • Express provides a stable API for interacting with most JavaScript runtime versions. Vulnerabilities within the JavaScript runtime itself or those requiring execution on an end-of-life version are not considered vulnerabilities in Express.

Comments on this Policy

If you have suggestions on how this process could be improved please submit a pull request.