detect-bidi-characters
detect-buffer-noassert
detect-child-process
exec()
function calls where the command passed to exec()
is not a literal string. This is crucial because dynamic commands based on user input can lead to arbitrary code execution, a severe security vulnerability.
require
expressions that load the “child_process” module unless these are part of a variable declaration, assignment, or a member expression. This narrow focus helps in pinpointing potentially hazardous code patterns where the module is imported without being directly assigned or used, which could indicate indirect or concealed usage.
exec()
function. Since literals are static and their content is known at the time of code writing, enforcing their use greatly reduces the risk of executing untrusted code. This constraint ensures that developers explicitly state command strings, making code inspection and auditing for insecure practices more straightforward.
detect-disable-mustache-escape
object.escapeMarkup = false
, which directly corresponds with turning off automatic escaping mechanisms. This is crucial because automatic escaping is a primary defense against XSS (Cross-Site Scripting) attacks.
escapeMarkup
property assignment to false
means that it is highly focused and is less likely to produce false positives. This focus helps maintain developer productivity by ensuring that only genuinely risky configurations are flagged for review and correction, without overwhelming developers with irrelevant warnings.
detect-eval-with-expression
eval()
with non-literal arguments within the code, which are typically susceptible to code injection attacks. By explicitly identifying calls where eval()
is invoked with variables or expressions possibly controlled by user input, developers are reminded to scrutinize and ideally avoid such usage patterns.
eval(variable)
, it encourages developers to look for safer alternatives to dynamic code evaluation based on untrusted inputs. The rule not only highlights dangerous patterns but implicitly guides towards safer coding practices by making developers aware of the risks associated with using eval()
in this manner.
JSON.parse()
for parsing JSON strings from untrusted sources instead of evaluating them as code. This specific guidance helps in reducing the security vulnerabilities associated with dynamic code execution, steering developers towards more secure methods of handling untrusted data.
eval()
. By enforcing its detection at the code analysis stage, it aids in preemptively mitigating risks associated with arbitrary code execution vulnerabilities, thereby contributing to the overall security posture of the application.
detect-new-buffer
new Buffer(argument)
with non-literal values, which is deprecated due to security vulnerabilities. Using non-literal values can lead to vulnerabilities where user input might be used to manipulate data or cause unintended behavior in the application.new Buffer(argument)
calls with the recommended Buffer.from(argument)
syntax, which is designed to handle data more safely, thereby reducing the potential for security vulnerabilities such as buffer overflow attacks.detect-no-csrf-before-method-override
express.csrf()
before express.methodOverride()
, this rule helps prevent potential security vulnerabilities where an attacker might exploit the ability to override HTTP methods in a way that bypasses CSRF protection mechanisms, potentially leading to CSRF attacks.app.use(csrf());
before app.use(methodOverride());
) assists in early detection and correction during development, contributing to a more secure codebase by preventing deployment of Express applications with configuration that could be exploited for CSRF attacks.detect-non-literal-fs-filename
fs
) module operations. By detecting non-literal filename arguments, it reduces the risk of arbitrary file access, where an attacker could potentially navigate the filesystem or access restricted files.fs
operations do not inadvertently process user-controlled input without validation, thus safeguarding against unauthorized access to the filesystem.fs
calls is dynamically generated, this rule helps maintain a stronger security posture within Node.js applications, making it harder for attackers to exploit vulnerabilities related to file access.detect-non-literal-regexp
detect-non-literal-require
require
are static literals, mitigating the risk of executing dynamically constructed module paths which can be manipulated by attackers to execute arbitrary code. This directly targets and reduces a significant vector for remote code execution vulnerabilities.
detect-object-injection
variable[key]
), it draws attention to code patterns that could be exploited for property injection attacks, thereby preventing possible security breaches.
detect-possible-timing-attacks
==
, !=
, !==
and ===
), which check input sequentially.==
, !=
, !==
, and ===
. These operations can leak timing information because they exit early as soon as a mismatch is found, potentially allowing attackers to deduce a correct value based on the time taken to evaluate the condition.crypto.timingSafeEqual
in Node.js, which are designed to compare data in a way that protects against timing attacks by ensuring that the operation takes the same amount of time regardless of the input.detect-pseudoRandomBytes
pseudoRandomBytes()
function from the Node.js crypto
module, which does not generate cryptographically secure random values. This is crucial for applications requiring high levels of security, such as in cryptographic operations, token generations, etc., where the predictability of random values could be exploited.
pseudoRandomBytes()
, the rule encourages developers to replace it with randomBytes()
, a function that generates cryptographically strong randomness. This simple switch considerably enhances the security posture of the application without requiring significant changes to the codebase.
detect-unsafe-regex
RegExp
objects, thus providing comprehensive coverage across different use cases and patterns in the codebase.