SonarJS Has 269 Rules and Found 13 Security Issues Where the Domain Plugins Found 46 — It's a Quality Linter

eslint-plugin-sonarjs is one of the best linters in the ecosystem — 269 rules, 3M+ weekly downloads, SonarSource's analysis engine distilled into ESLint. So I ran it against a file of 12 vulnerability classes alongside the Interlace security plugins. SonarJS flagged 13 security issues on that file; the domain plugins flagged 46 (different finding counts on the same file — not a shared scorecard).

That's not a knock on SonarJS. It's a scope result: SonarJS is a quality linter that happens to carry a handful of security rules. Security depth is a different product. Here's the reproducible data, and why "use both" is the real answer.

Detection — vulnerable.js (12 vulnerability classes)

SonarJS's 13 came from exactly the rules it ships for cross-language security basics: sonarjs/os-command (×3) + no-os-command-from-path (×1), sonarjs/sql-queries (×2), sonarjs/code-eval (×2), sonarjs/slow-regex (×2), sonarjs/hashing (×2), sonarjs/pseudo-random (×1). Those are genuinely good rules — os-command in particular is best-in-class. The same run also produced 25 quality findings (no-unused-vars, no-dead-store, …) — which is the point: SonarJS spends its 269 rules on quality, and a few of them overlap security.

The Interlace plugins surfaced 33 more findings — the Node-specific depth SonarJS has no rule for: fs-path traversal (node-security/detect-non-literal-fs-filename), object injection / prototype-pollution (secure-coding/detect-object-injection), PostgreSQL injection (pg/no-unsafe-query), unsafe deserialization (secure-coding/no-unsafe-deserialization), DOM XSS (browser-security/no-innerhtml), insecure comparisons, and more.

False positives — safe-patterns.js

SonarJS is precise — its 10 findings on the safe file were all quality (no-unused-vars), zero security false alarms. That precision is part of why it's a great quality tool.

Where SonarJS is the right call

• ✓ Cognitive complexity — one of the best implementations anywhere.
• ✓ Dead code / unused assignments / redundant logic — the no-dead-store, no-unused-collection, all-identical-comparison family.
• ✓ Code smells — duplicate branches, collapsible conditionals.
• ✓ The security basics — command injection, eval, weak hashing, insecure randomness, the SQL-string and slow-regex patterns above.

Where you need domain security rules

SonarJS has no rule for the Node-specific attack surface: fs path traversal, prototype pollution, NoSQL/Mongo injection, SSRF, open redirect, timing attacks, JWT claim validation, unsafe deserialization. Those are the gaps the domain plugins fill — not because SonarJS is weak, but because it was built for the breadth of JavaScript quality, not the depth of Node.js security.

The real answer: run both

SonarJS for quality, the domain plugins for security. They don't overlap enough to conflict, and together they cover both axes:

// eslint.config.mjs
import sonarjs from "eslint-plugin-sonarjs";
import { configs as secureCoding } from "eslint-plugin-secure-coding";
import { configs as nodeSecurity } from "eslint-plugin-node-security";
import { configs as pg } from "eslint-plugin-pg";
import { configs as browserSecurity } from "eslint-plugin-browser-security";

export default [
  sonarjs.configs.recommended, // quality
  secureCoding.recommended, // general security
  nodeSecurity.recommended, // crypto, supply-chain, SSRF, fs
  pg.recommended, // PostgreSQL
  browserSecurity.recommended, // DOM / browser
];

Methodology — reproduce it

Honest disclosure: the fixtures are team-authored (vulnerable.js, 12 vulnerability classes; safe-patterns.js, validated-safe patterns), so they measure coverage of the surface the Interlace rules target — run it on your own code for an unbiased read. Versions (measured 2026-05): eslint@9.39, oxlint@1.67, eslint-plugin-sonarjs@4.0.3 (269 rules), eslint-plugin-secure-coding@3.2.0, node-security@4.2.0, pg@1.4.3, browser-security@1.2.3. Each plugin's recommended preset, --format json, counted by ruleId (security rule IDs for the security totals).

npm i -D eslint@9 oxlint eslint-plugin-sonarjs eslint-plugin-secure-coding \
  eslint-plugin-node-security eslint-plugin-pg eslint-plugin-browser-security
npx eslint --config eslint.config.sonarjs.mjs test-files/vulnerable.js --format json
npx eslint --config eslint.config.interlace.mjs test-files/vulnerable.js --format json
npx oxlint test-files/vulnerable.js   # Oxlint built-in row

(On ESLint 8, set ESLINT_USE_FLAT_CONFIG=true to load eslint.config.mjs; ESLint 9+ uses flat config by default. The Interlace-flagship-on-Oxlint row is reproduced from the repo per the 4-way benchmark.)

The full 4-engine version of this benchmark (ESLint + Oxlint, built-in + plugins) is in the security-linter benchmark.

Compatibility

Links

• 📦 secure-coding · node-security · pg · browser-security
• 📦 eslint-plugin-sonarjs — the quality half
• 📖 Full rule docs
• 💻 Source on GitHub

⭐ Star on GitHub if you run SonarJS for quality and want the security half to match.

I'm Ofri Peretz, a security engineering leader and the author of the Interlace ESLint ecosystem — domain-specific static analysis for security, reliability, and performance on the Node.js stack.

ofriperetz.dev · LinkedIn · GitHub