Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
3 contributors

Users who have contributed to this file

@i0natan @js-kyle @BrunoScheufler
45 lines (28 sloc) 1.96 KB

Embrace linter security rules

One Paragraph Explainer

Security plugins for ESLint and TSLint such as eslint-plugin-security and tslint-config-security offer code security checks based on a number of known vulnerabilities, such as unsafe RegEx, unsafe use of eval(), and non-literal filenames being used when accessing the file system within an application. The use of git hooks such as pre-git allows to further enforce any rules on source control before they get distributed to remotes, one of which can be to check that no secrets were added to source control.

eslint-plugin-security example

Some examples of unsafe practice rules detected by eslint-plugin-security:

detect-pseudoRandomBytes

const insecure = crypto.pseudoRandomBytes(5);

detect-non-literal-fs-filename

const path = req.body.userinput;
fs.readFile(path);

detect-eval-with-expression

const userinput = req.body.userinput;
eval(userinput);

detect-non-literal-regexp

const unsafe = new RegExp('/(x+x+)+y/)');

An example of running eslint-plugin-security on a Node.js project with the above unsafe code practices:

nsp check example

What other bloggers say

From the blog by Adam Baldwin:

Linting doesn’t have to be just a tool to enforce pedantic rules about whitespace, semicolons or eval statements. ESLint provides a powerful framework for eliminating a wide variety of potentially dangerous patterns in your code (regular expressions, input validation, and so on). I think it provides a powerful new tool that’s worthy of consideration by security-conscious JavaScript developers.

You can’t perform that action at this time.