Benchmark: False Negatives & False Positives in ESLint Security Plugins

Skip to: Results Table | eslint-plugin-security | SonarJS | Microsoft SDL | Interlace | Methodology

TL;DR

I built a comprehensive benchmark with 40 vulnerable code patterns across 14 security categories and 38 safe patterns that should NOT trigger warnings. Then I ran six ESLint security plugins against them.

The Headline Numbers

Note: eslint-plugin-security crashes on ESLint 9. Its results are from ESLint 8.57.0. All other plugins were tested on ESLint 9.39.2.

Key Findings:

• eslint-plugin-security has a 1:1 true positive to false positive ratio — for every real issue it catches, it incorrectly flags a safe pattern
• eslint-plugin-sonarjs has 269 rules but only detects 35% of vulnerabilities — most rules target code quality, not security
• eslint-plugin-security-node (the "successor" to eslint-plugin-security) still misses 82.5% of vulnerabilities
• The Interlace ecosystem achieved a perfect score: 40/40 detections with zero false positives

Why This Benchmark Matters

Security linters exist to catch vulnerabilities before they reach production. But two failure modes undermine this mission:

False Negatives (missed vulnerabilities) create a dangerous illusion of security. Your CI pipeline passes, your code looks "clean," but invisible vulnerabilities ship to production.

False Positives (incorrectly flagged safe code) create alert fatigue. Developers start ignoring warnings, disabling rules, or worse—bypassing security checks entirely.

The ideal security linter has high recall (catches most vulnerabilities) and high precision (doesn't cry wolf).

The Benchmark Suite

Vulnerable Patterns (40 cases across 14 categories)

Safe Patterns (38 cases)

Secure implementations that should NOT trigger any warnings:

• Parameterized SQL queries (Prisma, TypeORM, pg)
• execFile with validated arguments
• path.resolve with startsWith validation
• Environment variables for credentials
• JWT with explicit algorithm restriction
• DOMPurify sanitization
• Allowlist validation before object access
• crypto.randomBytes for tokens
• crypto.timingSafeEqual for comparisons
• URL allowlists for SSRF prevention

The Results

Detection Summary

Vulnerable Code Detections (out of 40 patterns):

Interlace Ecosystem:         ████████████████████████████████████████  40 (100%)
eslint-plugin-sonarjs:       ██████████████░░░░░░░░░░░░░░░░░░░░░░░░░░  14 (35%)
eslint-plugin-security:      ███████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  11 (27.5%)
eslint-plugin-security-node: ███████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   7 (17.5%)
@microsoft/eslint-plugin-sdl:████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   4 (10%)
eslint-plugin-no-unsanitized:██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   2 (5%)

The Leaderboard

† Tested on ESLint 8.57.0 — crashes on ESLint 9 with TypeError: context.getScope is not a function

Plugin Deep Dives

eslint-plugin-security: The Incumbent

Weekly Downloads: 1.5M+ | Rules: 13 | Last Updated: 2024 | ESLint 9: ❌ Broken

What It Detected (11 violations)

What It Missed (29 patterns = 72.5% False Negative Rate)

The plugin has ZERO coverage for: SQL injection, hardcoded credentials, JWT attacks, weak crypto, NoSQL injection, SSRF, open redirects, and timing attacks.

The False Positive Problem (11 FPs = 100% of detections!)

For every vulnerability eslint-plugin-security catches, it also incorrectly flags a safe pattern:

FP #1-8: detect-object-injection (8 false positives)

// ✅ SAFE: Key validated against allowlist
const VALID_KEYS = ["name", "email", "age"];
if (VALID_KEYS.includes(key)) {
  return obj[key]; // ⚠️ Flagged as "Generic Object Injection Sink"
}

The rule flags any bracket notation with a variable, regardless of validation. It cannot recognize allowlist checks, hasOwnProperty guards, or Object.hasOwn() checks.

FP #9-11: detect-non-literal-fs-filename (3 false positives)

// ✅ SAFE: Path validated with startsWith
const safePath = path.resolve(baseDir, path.basename(filename));
if (!safePath.startsWith(baseDir + path.sep)) {
  throw new Error("Path traversal detected");
}
fs.readFileSync(safePath); // ⚠️ Flagged anyway

The rule cannot recognize path validation patterns.

ESLint 9 Compatibility: ❌ BROKEN

TypeError: context.getScope is not a function
Rule: "security/detect-child-process"

This is a breaking API change in ESLint 9. The plugin hasn't been updated, making it unusable with modern ESLint flat config.

eslint-plugin-sonarjs: The 269-Rule Giant

Weekly Downloads: 3M+ | Rules: 269 | Last Updated: 2025 (active) | ESLint 9: ✅ Works

Detection Results: 14/40 (35% Recall)

Despite having the most rules of any plugin tested, SonarJS missed 65% of vulnerabilities. The majority of its 269 rules target code quality (complexity, duplication, cognitive load), not security.

False Positives: 5

SonarJS had a 73.7% precision rate — better than eslint-plugin-security, but still means roughly 1 in 4 security warnings is noise.

📖 Deep dive: SonarJS vs Interlace: 269 Rules, 65% Missed

eslint-plugin-security-node: The Successor

Weekly Downloads: ~30K | Rules: 22 | Last Updated: 2023 | ESLint 9: ✅ Works

Created as a modern alternative to eslint-plugin-security, this plugin adds SQL injection and NoSQL injection detection rules that the original lacks. However, it still misses the majority of our test suite.

Detection Results: 7/40 (17.5% Recall)

False Positives: 4

A 63.6% precision rate — better than eslint-plugin-security's 50%, but still noisy.

@microsoft/eslint-plugin-sdl: Enterprise Security

Weekly Downloads: ~100K | Rules: 17 | Last Updated: 2024 (active) | ESLint 9: ✅ Works

Microsoft's Security Development Lifecycle plugin has the highest precision of any non-Interlace plugin (80%), but its scope is extremely narrow — focused almost entirely on browser-side injection patterns.

Detection Results: 4/40 (10% Recall)

False Positives: 1

High precision, but extremely limited coverage. Its 17 rules focus narrowly on XSS patterns — it has zero rules for SQL injection, command injection, path traversal, JWT attacks, or any server-side vulnerability.

📖 Deep dive: Microsoft SDL vs Interlace: Enterprise Security Benchmark

eslint-plugin-no-unsanitized (Mozilla)

Weekly Downloads: ~500K | Rules: 2 | Focus: XSS via DOM manipulation | ESLint 9: ⚠️ Limited

Detection Results: 2/40

False Positives: 1

// ✅ SAFE: Content sanitized with DOMPurify
const sanitized = DOMPurify.sanitize(userContent);
element.innerHTML = sanitized; // ⚠️ Flagged anyway

Very narrow scope. Useful as a supplement for XSS, but covers only 2 of 14 categories.

Interlace Ecosystem

Weekly Downloads: ~5K | Rules: 201 (11 specialized plugins) | ESLint 9: ✅ Works

Detection Results: 40/40 (100% Recall, 0 False Positives)

The Interlace ecosystem achieved a perfect score — detecting every vulnerability with zero false positives across all 14 categories.

Sample detections:

🔒 CWE-798 OWASP:A04-Cryptographic CVSS:9.8 | Hard-coded API key detected | CRITICAL
   Fix: Use environment variable: process.env.API_KEY

🔒 CWE-347 | Including "none" in algorithms array allows unsigned tokens | CRITICAL
   Fix: Remove "none" from the algorithms array

🔒 CWE-95 OWASP:A05-Injection CVSS:9.8 | eval() can be refactored to safer alternative | HIGH
   Fix: Remove eval entirely

The reason for 100% coverage is specialization. Instead of one monolithic plugin, the ecosystem uses purpose-built plugins for each domain: SQL (eslint-plugin-pg), JWT (eslint-plugin-jwt), crypto (eslint-plugin-crypto), browser XSS (eslint-plugin-browser-security), and more.

Category-by-Category Breakdown

† ESLint 8 results (crashes on ESLint 9)

What This Means for Your Team

The Math of Missing Vulnerabilities

If your codebase has 100 potentially vulnerable patterns:

The Alert Fatigue Cycle

When false positive rates are too high:

1. Developer sees detect-object-injection on config[key] where key is validated
2. Developer adds // eslint-disable-next-line
3. Repeat 50 times across codebase
4. Developer starts ignoring all security warnings
5. Real vulnerability slips through disabled rule
6. Breach

Methodology

Test Environment

† ESLint 8.57.0 used for eslint-plugin-security only (crashes on ESLint 9)

Fixture Design

All fixtures are:

• Realistic: Patterns from actual codebases, not contrived examples
• Reproducible: Published to GitHub with exact versions
• Comprehensive: All OWASP Top 10 with detectable patterns

Reproducibility

git clone https://github.com/ofri-peretz/eslint-benchmark-suite
cd eslint-benchmark-suite
npm install
npm run benchmark:fn-fp

# ESLint 8 benchmark (eslint-plugin-security)
cd benchmarks/fn-fp-comparison/eslint8-compat
npm install
npm run benchmark

Every claim in this article can be independently verified.

Conclusions

1. eslint-plugin-security is not viable for production. A 72.5% false negative rate and a 1:1 TP:FP ratio. It crashes on ESLint 9. There's no reason to use it in 2026.

2. eslint-plugin-sonarjs is a quality tool, not a security tool. Despite 269 rules and 3M+ downloads, it misses 65% of security vulnerabilities. Its strength is code quality enforcement.

3. eslint-plugin-security-node is better but still inadequate. It covers more categories than its predecessor, but still misses 82.5% of vulnerabilities.

4. @microsoft/eslint-plugin-sdl is high precision, low coverage. Excellent for browser XSS, but provides zero server-side security coverage.

5. The Interlace ecosystem delivers comprehensive coverage. 100% detection rate with zero false positives. Domain-specific plugins ensure deep coverage across all vulnerability categories.

6. Security tooling requires active maintenance. The OWASP landscape evolves. Plugins from 2020 don't cover JWT algorithm confusion, AI prompt injection, or modern SSRF patterns.

Migrate in 60 Seconds

npm uninstall eslint-plugin-security
npm install -D eslint-plugin-secure-coding eslint-plugin-node-security \
  eslint-plugin-browser-security eslint-plugin-crypto \
  eslint-plugin-pg eslint-plugin-jwt eslint-plugin-mongodb-security

// eslint.config.js
import secureCoding from "eslint-plugin-secure-coding";
import nodeSecurity from "eslint-plugin-node-security";
import browserSecurity from "eslint-plugin-browser-security";
import crypto from "eslint-plugin-crypto";

export default [
  secureCoding.configs.recommended,
  nodeSecurity.configs.recommended,
  browserSecurity.configs.recommended,
  crypto.configs.recommended,
];

Run ESLint. See what you've been missing.

Explore the Full Ecosystem

201 security rules. 11 specialized plugins. 100% OWASP Top 10 coverage.

The Interlace ESLint Ecosystem provides comprehensive security static analysis for modern Node.js applications.

📖 Documentation | ⭐ GitHub | 📦 NPM

Related Articles:

• I Benchmarked 17 ESLint Security Plugins. Only One Found Every Vulnerability.
• eslint-plugin-security Is Unmaintained
• I Let Claude Write 80 Functions. 65-75% Had Security Vulnerabilities.

Build Securely.

I'm Ofri Peretz, a Security Engineering Leader and the architect of the Interlace Ecosystem. I build static analysis standards that automate security and performance for Node.js fleets at scale.

ofriperetz.dev | LinkedIn | GitHub