Keep the rules that flag specific dangerous calls, such as eval with a variable and child_process with non-literal input, as errors. Treat the broad ones, like object injection and non-literal filenames, as review prompts. The project README itself says it finds many false positives that need human triage.
What the plugin contains
The eslint-plugin-security README lists fifteen rules. All except detect-bidi-characters are in the recommended config. That one is set to warn and is not enabled by recommended. The flat config setup is short:
const pluginSecurity = require('eslint-plugin-security');
module.exports = [pluginSecurity.configs.recommended];
It requires ESLint 8.23.0 or later, per the README.
A way to sort the rules
| Group | Rules | Suggested use |
|---|---|---|
| Specific dangerous calls | detect-eval-with-expression, detect-child-process, detect-non-literal-require, detect-new-buffer, detect-buffer-noassert, detect-pseudoRandomBytes | Error, fix or justify each |
| Character tricks | detect-bidi-characters, detect-invisible-characters | Error. Few false positives |
| Denial of service | detect-unsafe-regex, detect-non-literal-regexp | Error for unsafe regex, review the second |
| Broad data flow guesses | detect-object-injection, detect-non-literal-fs-filename, detect-possible-timing-attacks | Warn, triage, suppress with a reason |
| Framework specific | detect-no-csrf-before-method-override, detect-disable-mustache-escape | Keep if you use those libraries |
Why the broad rules are noisy
detect-object-injection flags variable[key] on either side of an assignment. Plenty of safe code does that, such as reading from a map you built. The rule cannot know where key came from. It is still useful to look at once, because the unsafe version, writing to a user supplied key on a plain object, is the shape behind prototype pollution. See prototype pollution defenses.
detect-non-literal-fs-filename flags any fs call with a variable path. Again most are safe. Review the ones where the path comes from a request.
A rollout plan
- Enable recommended in a branch and export the findings to a file.
- Group findings by rule and count them.
- Fix the specific call rules first, since each hit is a real question.
- For broad rules, sample twenty findings, note how many are real, and decide whether to keep the rule as a warning.
- Suppress with a comment that states why the input is trusted. A bare disable comment hides the question from the next reviewer.
- Revisit in a quarter.
What linters like this cannot do
They match code shapes. They do not follow data from a request through function calls, and they cannot tell if a dependency has a known vulnerability. Pair linting with dependency scanning and reachability analysis, and see SAST for JavaScript and TypeScript for where each fits.
Try it yourself
Open the code scan demo and compare the findings with what pattern matching alone would report.
Click through it at your own pace, or open it full screen.
Safeguard scans dependencies and applies reachability analysis so you can focus on what your code actually calls. Try a free scan.
Quick check
Is detect-bidi-characters enabled by the recommended config?
No. The README says it is set to warn and not enabled by recommended.
Are the findings confirmed vulnerabilities?
No. The README says to treat them as hotspots for human review.
Sources
Last reviewed: 19 October 2026.
