1# Security 2 3## Reporting a bug in Node.js 4 5Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs). 6 7Normally your report will be acknowledged within 5 days, and you'll receive 8a more detailed response to your report within 10 days indicating the 9next steps in handling your submission. These timelines may extend when 10our triage volunteers are away on holiday, particularly at the end of the 11year. 12 13After the initial reply to your report, the security team will endeavor to keep 14you informed of the progress being made towards a fix and full announcement, 15and may ask for additional information or guidance surrounding the reported 16issue. 17 18### Node.js bug bounty program 19 20The Node.js project engages in an official bug bounty program for security 21researchers and responsible public disclosures. The program is managed through 22the HackerOne platform. See <https://hackerone.com/nodejs> for further details. 23 24## Reporting a bug in a third party module 25 26Security bugs in third party modules should be reported to their respective 27maintainers. 28 29## Disclosure policy 30 31Here is the security disclosure policy for Node.js 32 33* The security report is received and is assigned a primary handler. This 34 person will coordinate the fix and release process. The problem is validated 35 against all supported Node.js versions. Once confirmed, a list of all affected 36 versions is determined. Code is audited to find any potential similar 37 problems. Fixes are prepared for all supported releases. 38 These fixes are not committed to the public repository but rather held locally 39 pending the announcement. 40 41* A suggested embargo date for this vulnerability is chosen and a CVE (Common 42 Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability. 43 44* On the embargo date, the Node.js security mailing list is sent a copy of the 45 announcement. The changes are pushed to the public repository and new builds 46 are deployed to nodejs.org. Within 6 hours of the mailing list being 47 notified, a copy of the advisory will be published on the Node.js blog. 48 49* Typically the embargo date will be set 72 hours from the time the CVE is 50 issued. However, this may vary depending on the severity of the bug or 51 difficulty in applying a fix. 52 53* This process can take some time, especially when coordination is required 54 with maintainers of other projects. Every effort will be made to handle the 55 bug in as timely a manner as possible; however, it's important that we follow 56 the release process above to ensure that the disclosure is handled in a 57 consistent manner. 58 59## The Node.js threat model 60 61In the Node.js threat model, there are trusted elements such as the 62underlying operating system. Vulnerabilities that require the compromise 63of these trusted elements are outside the scope of the Node.js threat 64model. 65 66For a vulnerability to be eligible for a bug bounty, it must be a 67vulnerability in the context of the Node.js threat model. In other 68words, it cannot assume that a trusted element (such as the operating 69system) has been compromised. 70 71Being able to cause the following through control of the elements that Node.js 72does not trust is considered a vulnerability: 73 74* Disclosure or loss of integrity or confidentiality of data protected through 75 the correct use of Node.js APIs. 76* The unavailability of the runtime, including the unbounded degradation of its 77 performance. 78 79If Node.js loads configuration files or runs code by default (without a 80specific request from the user), and this is not documented, it is considered a 81vulnerability. 82Vulnerabilities related to this case may be fixed by a documentation update. 83 84**Node.js does NOT trust**: 85 861. Data received from the remote end of inbound network connections 87 that are accepted through the use of Node.js APIs and 88 which is transformed/validated by Node.js before being passed 89 to the application. This includes: 90 * HTTP APIs (all flavors) server APIs. 912. The data received from the remote end of outbound network connections 92 that are created through the use of Node.js APIs and 93 which is transformed/validated by Node.js before being passed 94 to the application EXCEPT in respect to payload length. Node.js trusts 95 that applications make connections/requests which will avoid payload 96 sizes that will result in a Denial of Service. 97 * HTTP APIs (all flavors) client APIs. 98 * DNS APIs. 993. Consumers of data protected through the use of Node.js APIs (for example 100 people who have access to data encrypted through the Node.js crypto APIs). 1014. The file content or other I/O that is opened for reading or writing by the 102 use of Node.js APIs (ex: stdin, stdout, stderr). 103 104In other words, if the data passing through Node.js to/from the application 105can trigger actions other than those documented for the APIs, there is likely 106a security vulnerability. Examples of unwanted actions are polluting globals, 107causing an unrecoverable crash, or any other unexpected side effects that can 108lead to a loss of confidentiality, integrity, or availability. 109 110**Node.js trusts everything else**. As some examples this includes: 111 1121. The developers and infrastructure that runs it. 1132. The operating system that Node.js is running under and its configuration, 114 along with anything under control of the operating system. 1153. The code it is asked to run including JavaScript and native code, even if 116 said code is dynamically loaded, e.g. all dependencies installed from the 117 npm registry. 118 The code run inherits all the privileges of the execution user. 1194. Inputs provided to it by the code it is asked to run, as it is the 120 responsibility of the application to perform the required input validations, 121 e.g. the input to `JSON.parse()`. 1225. Any connection used for inspector (debugger protocol) regardless of being 123 opened by command line options or Node.js APIs, and regardless of the remote 124 end being on the local machine or remote. 1256. The file system when requiring a module. 126 See <https://nodejs.org/api/modules.html#all-together>. 127 128Any unexpected behavior from the data manipulation from Node.js Internal 129functions may be considered a vulnerability if they are exploitable via 130untrusted resources. 131 132In addition to addressing vulnerabilities based on the above, the project works 133to avoid APIs and internal implementations that make it "easy" for application 134code to use the APIs incorrectly in a way that results in vulnerabilities within 135the application code itself. While we don’t consider those vulnerabilities in 136Node.js itself and will not necessarily issue a CVE we do want them to be 137reported privately to Node.js first. 138We often choose to work to improve our APIs based on those reports and issue 139fixes either in regular or security releases depending on how much of a risk to 140the community they pose. 141 142### Examples of vulnerabilities 143 144#### Improper Certificate Validation (CWE-295) 145 146* Node.js provides APIs to validate handling of Subject Alternative Names (SANs) 147 in certificates used to connect to a TLS/SSL endpoint. If certificates can be 148 crafted which result in incorrect validation by the Node.js APIs that is 149 considered a vulnerability. 150 151#### Inconsistent Interpretation of HTTP Requests (CWE-444) 152 153* Node.js provides APIs to accept http connections. Those APIs parse the 154 headers received for a connection and pass them on to the application. 155 Bugs in parsing those headers which can result in request smuggling are 156 considered vulnerabilities. 157 158#### Missing Cryptographic Step (CWE-325) 159 160* Node.js provides APIs to encrypt data. Bugs that would allow an attacker 161 to get the original data without requiring the decryption key are 162 considered vulnerabilities. 163 164#### External Control of System or Configuration Setting (CWE-15) 165 166* If Node.js automatically loads a configuration file which is not documented 167 and modification of that configuration can affect the confidentiality of 168 data protected using the Node.js APIs this is considered a vulnerability. 169 170### Examples of non-vulnerabilities 171 172#### Malicious Third-Party Modules (CWE-1357) 173 174* Code is trusted by Node.js, therefore any scenario that requires a malicious 175 third-party module cannot result in a vulnerability in Node.js. 176 177#### Prototype Pollution Attacks (CWE-1321) 178 179* Node.js trusts the inputs provided to it by application code. 180 It is up to the application to sanitize appropriately, therefore any scenario 181 that requires control over user input is not considered a vulnerability. 182 183#### Uncontrolled Search Path Element (CWE-427) 184 185* Node.js trusts the file system in the environment accessible to it. 186 Therefore, it is not a vulnerability if it accesses/loads files from any path 187 that is accessible to it. 188 189#### External Control of System or Configuration Setting (CWE-15) 190 191* If Node.js automatically loads a configuration file which is documented 192 no scenario that requires modification of that configuration file is 193 considered a vulnerability. 194 195#### Uncontrolled Resource Consumption (CWE-400) on outbound connections 196 197* If Node.js is asked to connect to a remote site and return an 198 artifact, it is not considered a vulnerability if the size of 199 that artifact is large enough to impact performance or 200 cause the runtime to run out of resources. 201 202## Assessing experimental features reports 203 204Experimental features are eligible to reports as any other stable feature of 205Node.js. They will also be susceptible to receiving the same severity score 206as any other stable feature. 207 208## Receiving security updates 209 210Security notifications will be distributed via the following methods. 211 212* <https://groups.google.com/group/nodejs-sec> 213* <https://nodejs.org/en/blog/> 214 215## Comments on this policy 216 217If you have suggestions on how this process could be improved please submit a 218[pull request](https://github.com/nodejs/nodejs.org) or 219[file an issue](https://github.com/nodejs/security-wg/issues/new) to discuss. 220