The threat environment for Node.js is similar to that for other runtimes that are primarily used for microservices and web frontends, but there are some Node.js specific concerns.
We define both kinds of threats in this section. A reader familiar with web-application security can skip all but this page and the discussion of unintended require without missing much, but may find it helpful to refer back to the table below when reading later chapters.
same-origin policy possibly with a
Content-Security-Policy which governs which code can load.
constrained by the files on the server, and the values that can
eval(...)and similar operators.
- File-system access by the client typically either requires human
Content-disposition:attachment), or can only access a directory dedicated to third-party content (browser cache, local storage) and which is not usually on a list like
$PATH. On the server, the Node runtime process's privileges determine file-system access.
well-understood APIs like
- Client-side, the browser halts all scripts in a document when a single event loop cycle runs too long. Node.js has few ways to manage runaway computations on the server.
Classes of Threats
The table below lists broad classes of vulnerabilities, and for each, a short identifier by which we refer to the class later in this document. This list is not meant to be comprehensive, but we expect that a thorough security assessment would touch on most of these and would have low confidence in an assessment that skips many.
The frequency and severity of vulnerabilities are guesstimates since we have little hard data on the frequency of these in Node.js applications, so have extrapolated from similar systems. For example, see discussion about frequency in buffer overflow.
For each, relevant mitigation strategies appear in the mitigations columns, and link to the discussion.
|0DY||Zero-day. Attackers exploit a vulnerability before a fix is available.||Low-Med||Med-High||cdeps fail|
|CRY||Misuse of crypto leads to poor access-control decisions or data leaks.||Medium||Medium||ovrsi|
|DEX||Poor developer experience slows or prevents release of features.||?||?||dynam ovrsi|
|DOS||Denial of service||Medium||Low-Med||TBD|
|EXF||Exfiltration of data, e.g. by exploiting reflection to serialize more than intended.||Med-High||Low-Med||ovrsi|
|LQC||Using low quality dependencies leads to exploit||Medium||Low-Med||kdeps ovrsi|
|MTP||Theft of commit rights or MITM causes
|QUI||Query injection on a production machine.||Medium||Med-High||ovrsi qlang|
|RCE||Remote code execution, e.g. via
|SHP||Shell injection on a production machine.||Low||High||ovrsi cproc|
Meltdown and Spectre
As of this writing, the security community is trying to digest the implications of Meltdown and Spectre. The Node.js blog addresses them from a Node.js perspective, so we do not comment in depth.
It is worth noting though that those vulnerabilities lead to breaches of confidentiality. While confidentiality violations are serious, the suggestions that follow use design principles that prevent a violation of confidentiality from causing a violation of integrity. Specifically:
- Knowing a whitelist of production source hashes does not allow an attacker to cause a non-production source to load.
- Our runtime