OSSForks/node
1
0
Fork 0
mirror of https://github.com/zebrajr/node.git synced 2026-01-15 12:15:26 +00:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity

doc: clarify threat model for application-level API exposure

Browse Source 
Add examples of non-vulnerabilities when applications expose Node.js
APIs to untrusted users without proper security boundaries.

PR-URL: https://github.com/nodejs/node/pull/61184
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
This commit is contained in:
Rafael Gonzaga
2025-12-29 21:07:14 -03:00
committed by GitHub
parent 5c8ce910bd
commit 4031355dd6
1 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
SECURITY.md
View File

@@ -309,6 +309,32 @@ the community they pose.
Node.js releases won't be affected by such vulnerabilities. Users are
responsible for keeping the software they use through Corepack up-to-date.
#### Exposing Application-Level APIs to Untrusted Users (CWE-653)
* Node.js trusts the application code that uses its APIs. When application code
exposes Node.js functionality to untrusted users in an unsafe manner, any
resulting crashes, data corruption, or other issues are not considered
vulnerabilities in Node.js itself. It is the application's responsibility to:
* Validate and sanitize all untrusted input before passing it to Node.js APIs.
* Design appropriate access controls and security boundaries.
* Avoid exposing low-level or dangerous APIs directly to untrusted users.
* Examples of scenarios that are **not** Node.js vulnerabilities:
* Allowing untrusted users to register SQLite user-defined functions that can
perform arbitrary operations (e.g., closing database connections during query
execution, causing crashes or use-after-free conditions).
* Exposing `child_process.exec()` or similar APIs to untrusted users without
proper input validation, allowing command injection.
* Allowing untrusted users to control file paths passed to file system APIs
without validation, leading to path traversal issues.
* Permitting untrusted users to define custom code that executes with the
application's privileges (e.g., custom transforms, plugins, or callbacks).
* These scenarios represent application-level security issues, not Node.js
vulnerabilities. The root cause is the application's failure to establish
proper security boundaries between trusted application logic and untrusted
user input.
## Assessing experimental features reports
Experimental features are eligible for security reports just like any other