Repository: nodejs/node
Pull request: meta: expand memory leak DoS criteria to all DoS

We have dedicated requirements about memory leaks when triaging DoS. These applies in generall to all types of DoS, and many recent reports about DoS attack vectors fail to meet them, resulting in a lot of extra back-and-forth in triaging. Clarify in the threat model by expanding these requirements to all DoS.

Drive-by: clarify criteria of documented JavaScript behavior is that they are included in ECMA262. Also use "Node.js application developer" instead of "user" the refer to the party being vulnerable to avoid confusion.

<!--
Before submitting a pull request, please read:

- the CONTRIBUTING guide at https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md
- the commit message formatting guidelines at
  https://github.com/nodejs/node/blob/HEAD/doc/contributing/pull-requests.md#commit-message-guidelines

For code changes:
1. Include tests for any bug fixes or new features.
2. Update documentation if relevant.
3. Ensure that `make -j4 test` (UNIX), or `vcbuild test` (Windows) passes.

If you believe this PR should be highlighted in the Node.js CHANGELOG
please add the `notable-change` label.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.
-->


Changed files:
filename: SECURITY.md
patch: @@ -152,28 +152,33 @@ does not trust is considered a vulnerability:
   the correct use of Node.js APIs.
 * The unavailability of the runtime, including the unbounded degradation of its
   performance.
-* Memory leaks qualify as vulnerabilities when all of the following criteria are met:
-  * The API is being correctly used.
-  * The API doesn't have a warning against its usage in a production environment.
-  * The API is public and documented.
-  * The API is on stable (2.0) status.
-  * The memory leak is significant enough to cause a denial of service quickly
-    or in a context not controlled by the user (for example, HTTP parsing).
-  * The memory leak is directly exploitable by an untrusted source without requiring application mistakes.
-  * The leak cannot be reasonably mitigated through standard operational practices (like process recycling).
-  * The leak occurs deterministically under normal usage patterns rather than edge cases.
-  * The leak occurs at a rate that would cause practical resource exhaustion within a practical timeframe under
-    typical workloads.
-  * The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html),
-    where the attacker expends significantly fewer resources than what's required by the server to process the
-    attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common
-    practices like rate limiting) may not qualify.
 
 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.
 
+#### Denial of Service (DoS) vulnerabilities
+
+For a behavior to be considered a DoS vulnerability, the PoC must meet the following criteria:
+
+* The API is being correctly used.
+* The API doesn't have a warning against its usage in a production environment.
+* The API is public and documented. If the API comes from JavaScript, the behavior must be
+  well-defined in the [ECMAScript specification](https://tc39.es/ecma262/).
+* The API has stable (2.0) status.
+* The behavior is significant enough to cause a denial of service quickly
+  or in a context not controlled by the Node.js application developer (for example, HTTP parsing).
+* The behavior is directly exploitable by an untrusted source without requiring application mistakes.
+* The behavior cannot be reasonably mitigated through standard operational practices (like process recycling).
+* The behavior occurs deterministically under normal usage patterns rather than edge cases.
+* The behavior occurs at a rate that would cause practical resource exhaustion within a practical timeframe under
+  typical workloads.
+* The attack demonstrates [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html),
+  where the attacker expends significantly fewer resources than what's required by the server to process the
+  attack. Attacks requiring comparable resources on the attacker's side (which can be mitigated through common
+  practices like rate limiting) may not qualify.
+
 **Node.js does NOT trust**:
 
 * Data received from the remote end of inbound network connections