Articles

How to prevent MongoDB NoSQL injection, operator injection, and hardcoded connection strings with the only ESLint plugin built specifically for MongoDB/Mongoose.

Same prompt. Claude Sonnet 4.6 got 6 security errors from eslint-plugin-nestjs-security. Gemini 2.5 Flash got 2. Both missed rate limiting on auth endpoints — and Gemini got guards, validators, and serialization right where Claude didn't.

I gave Claude one prompt and got 200 lines of correct NestJS. TypeScript compiled clean. Then I ran eslint-plugin-nestjs-security. 6 errors, 3 seconds. Here is what it found and why each one is an AI failure mode.

Our cycle detector returned 0 on a 14K-file repo. oxlint found 17. We audited the rule and found two bugs: a 10-hop depth limit that silenced cycles longer than 10 hops, and a cache contamination bug that made results non-deterministic across runs.

We found 5 import cycles in 33 files that were invisible in 14,556. The cause: a 10-hop depth limit that wrote false non-cyclic entries into a shared cache, poisoning later traversals. Here is the bug, the fix, and how to test if your own cycle detector has the same class of failure.

The codebase had 2 years of feature PRs and zero security audits. In 30 minutes, a fresh ESLint run surfaced 6 distinct vulnerability classes — auth bypass, sensitive field leaks, brute-force exposure, and three more. Here's what each one looks like and why it survived code review.

I ran 40 real-world vulnerable patterns through every major ESLint security plugin — from eslint-plugin-security to SonarJS to Microsoft SDL. The detection gaps are alarming.

Part 3 ranked 5 AI models by overall vulnerability rate. But when we broke the data down by security domain — database, auth, file I/O, command execution — the rankings inverted. The 'worst' model fixes 93% of database vulnerabilities. The 'best' model fails at remediation. Aggregate numbers hide domain expertise.

700 AI-generated functions. 5 models. The cheapest model leads the aggregate leaderboard — but one model writes perfect JWT code where the flagship fails every time, and the 'worst' model fixes 93% of database bugs. The rankings don't tell you any of this.

When AI models fix security vulnerabilities, they sometimes introduce entirely new ones. I tested this across 3 remediation rounds with Claude Opus 4.6 using two approaches — ESLint-guided feedback vs. prompt engineering alone. The results expose a fundamental limit of 'fix it again' workflows.

eslint-plugin-security is the foundational, generic Node security linter — 14 rules, 2.4M+ weekly downloads, actively maintained. It catches the cross-cutting classics; it isn't built for SQL, JWT, crypto, or AI depth. Here's what each layer covers and how to run them together.

AI coding assistants are incredible—until they introduce security holes. I ran an experiment asking Claude (Haiku 3.5, Sonnet 4.5, Opus 4.5, Opus 4.6) to generate 80 common Node.js functions with zero security context using my Claude Pro subscription. 65-75% had vulnerabilities. Then I tested if static analysis could help the models fix their own mistakes.