The Semgrep registry now has 3 fresh rulesets for the JavaScript ecosystem:

• We upgraded the p/javascript ruleset so that it is applicable to a broader scope of targets

• Put high quality rules for the Node.js API in a new p/nodejs ruleset

• and created p/expressjs set that covers common Express.js misconfigurations.

The first version of our JavaScript ruleset was the collection of our best rules in terms of performance and false positive rate. Even though the rules in this ruleset were of good quality, they not always were meeting users’ expectations. Because JavaScript nowadays is used widely in many different situations, some developers expected to see rules for code that runs in the browsers, while others supposed that rules going to scan Express.js code. The ruleset was targeting client-side vulnerabilities, code correctness, JWT mistakes, and some Node.js bugs all at the same time. Since Semgrep and its rule quality matured, we decided to create multiple rulesets so that each one had a clear and understandable purpose.

On the graph you can see number of rules in each ruleset and how they are distributed. The Node.js ruleset includes p/javascript and the Express.js ruleset also has p/nodejs and p/javascript rules inside, so there is no need to run multiple rulesets at once. Feel free to use them locally or inside your CI/CD environment.

Details

We wanted to make JavaScript rulesets applicable to a large scope of code bases. That is why we focused on writing rules that cover core concepts, rather than trying to cover vulnerabilities in third-party libraries. We still include some rules that find bugs in code that use dependencies, but only those that are widespread and popular.

JavaScript:

To run the Semgrep JavaScript ruleset, use:

semgrep --config "p/javascript"

We decided to write patterns to identify vulnerabilities in both client-side and server-side code. Some of them:

• bracket object injection

  Object injection via bracket notation. It looks innocent but it can lead to severe problems like prototype pollution, hidden property attacks or various business logic bypasses.

• prototype pollution

  A trending vulnerability nowadays, there’s lots of research in this field going on (e.g. this or this one) and you definitely do not want to be affected by it. Its possible impacts vary from XSS to RCE.

• non literal regex

  RegExp() called with a variable may allow an attacker to DOS your application.

• hardcoded secrets

  Multiple rules for finding hardcoded API keys will always be appropriate.

• and many more...

Node.js:

To run the Semgrep Node.js ruleset, use:

semgrep --config "p/nodejs"

We tried to cherry-pick those rules that work only with the Node.js API.

• shell parameter set to true

  Setting shell to true when spawning commands with Node.js is the first step to command injection, so it is important to track this invariant in your code.

• pseudo random bytes

  Usage of deprecated pseudoRandomBytes function - weak random number generator

• TLS misconfigurations and bypasses

  Multiple rules for identifying disabled TLS verification and outdated TLS versions are very useful if your app sends or receives data from outside the company network.

• weak hashes

  Simple but effective rules that highlight weak and broken hashing algorithms, like SHA1, MD5, AES with ECB etc.

• check out full list here

Express:

To run the Semgrep Express.js ruleset, use:

semgrep --config "p/expressjs"

We chose to cover the most common misconfigurations in the framework and the most popular libraries that are widely used with Express.

• CORS misconfiguration

  Wrongly configured CORS can be a gateway for complex exploit chains in a web application. It is better to mitigate this risk.

• default cookie settings

  We have multiple rules that can help harden the application's cookie settings and not let an attacker steal critical information.

• response injection

  Letting user input into web application response can result in an XSS vulnerability. We have rules that help to mitigate this risk.

• XSS bugs from our previous research

  We did in-depth research on how XSS can be introduced in an Express application, so we included all of the rules from that research.

Next steps

We plan to upgrade and bring better coverage for all languages and frameworks that we support. Stay tuned for updates. If you have ideas or wishes for new or existing rulesets, we'd love to hear from you!