Commit f418fcc
committed
doc: clarify threat model for application-level API exposure
Add examples of non-vulnerabilities when applications expose Node.js
APIs to untrusted users without proper security boundaries.
PR-URL: #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>1 parent 1186108 commit f418fcc
1 file changed
Lines changed: 26 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -309,6 +309,32 @@ the community they pose. | |||
| 309 | 309 | Node.js releases won't be affected by such vulnerabilities. Users are | |
| 310 | 310 | responsible for keeping the software they use through Corepack up-to-date. | |
| 311 | 311 | ||
| 312 | + #### Exposing Application-Level APIs to Untrusted Users (CWE-653) | ||
| 313 | + | ||
| 314 | + * Node.js trusts the application code that uses its APIs. When application code | ||
| 315 | + exposes Node.js functionality to untrusted users in an unsafe manner, any | ||
| 316 | + resulting crashes, data corruption, or other issues are not considered | ||
| 317 | + vulnerabilities in Node.js itself. It is the application's responsibility to: | ||
| 318 | + * Validate and sanitize all untrusted input before passing it to Node.js APIs. | ||
| 319 | + * Design appropriate access controls and security boundaries. | ||
| 320 | + * Avoid exposing low-level or dangerous APIs directly to untrusted users. | ||
| 321 | + | ||
| 322 | + * Examples of scenarios that are **not** Node.js vulnerabilities: | ||
| 323 | + * Allowing untrusted users to register SQLite user-defined functions that can | ||
| 324 | + perform arbitrary operations (e.g., closing database connections during query | ||
| 325 | + execution, causing crashes or use-after-free conditions). | ||
| 326 | + * Exposing `child_process.exec()` or similar APIs to untrusted users without | ||
| 327 | + proper input validation, allowing command injection. | ||
| 328 | + * Allowing untrusted users to control file paths passed to file system APIs | ||
| 329 | + without validation, leading to path traversal issues. | ||
| 330 | + * Permitting untrusted users to define custom code that executes with the | ||
| 331 | + application's privileges (e.g., custom transforms, plugins, or callbacks). | ||
| 332 | + | ||
| 333 | + * These scenarios represent application-level security issues, not Node.js | ||
| 334 | + vulnerabilities. The root cause is the application's failure to establish | ||
| 335 | + proper security boundaries between trusted application logic and untrusted | ||
| 336 | + user input. | ||
| 337 | + | ||
| 312 | 338 | ## Assessing experimental features reports | |
| 313 | 339 | ||
| 314 | 340 | Experimental features are eligible for security reports just like any other | |
0 commit comments