DEV Community: Ofri Peretz

Everyone Greps for SQL Injection. Nobody Greps for the Other Eight.

Ofri Peretz — Sun, 27 Sep 2026 19:27:57 +0000

Ask a developer to find injection in a codebase and they grep for string concatenation near a database call. They will find the SQL. They will walk past eight other interpreters on the way.

An interpreter nobody remembers is still an interpreter. Build a string, hand it to something that parses it, and you have the same bug — whether or not that parser speaks SQL.

The shape, not the syntax

The taxonomy already knew this. CWE-943 is "Improper Neutralization of Special Elements in Data Query Logic" — the parent class that SQL injection is merely the famous child of. Its siblings are the same defect aimed at different parsers.

Injection	CWE	The interpreter you forgot
GraphQL	CWE-943	the query resolver
LDAP	CWE-90	the directory filter
XPath	CWE-643	the XML path engine
XXE	CWE-611	the XML entity resolver
Template	CWE-94	the template compiler
Directive	CWE-96	the server-side include
Format string	CWE-134	the format specifier parser
Object / prototype	CWE-915	the JavaScript engine itself

Be precise about what that parent covers: the honest version is narrower than the tidy one. MITRE lists exactly four children under CWE-943 — check the Research Concepts view (View-1000) on that page — and all four are query languages: SQL (CWE-89), LDAP (CWE-90), XPath (CWE-643) and XQuery (CWE-652).

Everything else in the table is commonly mapped there, not formally filed under it. GraphQL has no dedicated CWE at all; neither do the NoSQL operator injections. And XXE, format string and prototype pollution are not siblings — they are separate defects that happen to share a blind spot, not a parent.

Eight interpreters plus SQL, in two distinct shapes — data-query injection (the CWE-943 family) and code/context injection (everything else in the table). SQL got the name people recognise. The parser inside your LDAP filter did not, and that is the entire reason it goes unaudited.

Three that fail in ways SQL does not

XXE needs no injected operator at all. Parse attacker-supplied XML with entity resolution enabled and the parser fetches local files on their behalf. There is no quote to escape, no operator to smuggle. The payload is the document.

LDAP fails silently. (uid= plus a string is a filter, and a stray ) turns an authentication check into a wildcard matching every entry in the directory. No error, no stack trace — a login that simply succeeds.

Template injection escalates further than SQL. PortSwigger's server-side template injection research showed a template engine will hand over remote code execution as readily as a database hands over rows. A templating call is not a formatting convenience; it is an evaluator.

GraphQL is the odd one, because injection is only half of it. A query the client shapes is also a cost problem — the caller, not you, decides how many nested resolvers run. That is resource exhaustion (CWE-400) wearing a query's clothes, and why a depth limit is a security control, not a performance tweak.

Why grep finds SQL and misses the rest

OWASP folds this whole family into A03. Most tooling does not, because a pattern matcher looks for a sink it has been taught — a query(, an execute(. Nobody teaches it XPathEvaluator, libxmljs, an LDAP filter:, a compile(.

That is also the honest limit of pattern matching. Seeing a + flowing into a sink does not prove the value came from a request, and it goes quiet when the concatenation happens one helper away. That gap between "looks dangerous" and "is reachable" is the whole subject of taint analysis.

What to actually do

Do not start from a checklist. Grep your own code for the constructors: XPathEvaluator, libxmljs, an LDAP filter:, a template compile(, any %s you assemble by hand. For each, ask one question — can user input reach this string?

Grep is the triage list, not the verdict: it tells you where to look, taint tells you whether it reaches.

If the answer is "probably not, but I would have to check", that is exactly the answer most people give about SQL right before they find the other eight.

Which interpreter is live in your stack right now that you have never grepped for? My money is on GraphQL.

More on how these classes get named and ranked: the CWE taxonomy and the OWASP Top 10. I write these at dev.to/ofri-peretz.

⭐ Star the repo if you would rather your linter knew about the other eight interpreters too.

One Import Moves a commander CLI to burgee. --json Still Says null.

Ofri Peretz — Wed, 23 Sep 2026 15:28:33 +0000

I changed one line in a commander CLI:

- import { Command } from "commander";
+ import { Command } from "burgee/commander";

Help, output, errors and exit codes stayed byte-identical on seven invocations. The same file also answers --schema, --mcp and completion <shell>. And --json answers "data":null.

One import describes the CLI to an agent; answering takes a return. I maintain burgee; everything below ran on commander@15.0.0 and burgee@0.11.1.

The program

Plain commander, ESM, as cli.commander.js:

#!/usr/bin/env node
import { readFileSync } from "node:fs";
import { Command } from "commander";

const program = new Command();
program
  .name("lines")
  .description("Count and rank the lines in a text file")
  .version("1.0.0");

program
  .command("count")
  .description("count the lines in a file")
  .argument("<file>", "file to read")
  .option("--skip-blank", "ignore empty lines")
  .action((file, opts) => {
    let lines = readFileSync(file, "utf8").trimEnd().split("\n");
    if (opts.skipBlank) lines = lines.filter((l) => l.trim() !== "");
    console.log(`${lines.length} lines in ${file}`);
  });

program
  .command("longest")
  .description("print the longest lines in a file")
  .argument("<file>", "file to read")
  .option("-n, --top <count>", "how many lines to show", "3")
  .action((file, opts) => {
    const lines = readFileSync(file, "utf8").trimEnd().split("\n");
    const top = lines
      .sort((a, b) => b.length - a.length)
      .slice(0, Number(opts.top));
    for (const line of top)
      console.log(`${String(line.length).padStart(4)}  ${line}`);
  });

program.parse();

The swap

npm install commander@15.0.0 burgee@0.11.1   # or: yarn/pnpm/bun add
npm pkg set type=module
cp cli.commander.js cli.js
printf 'alpha\n\nbravo charlie\ndelta echo foxtrot golf\n\nhotel\n' > sample.txt

All four work, as does require(). TypeScript's legacy node resolver cannot see the subpath. After the import swap in cli.js:

$ diff <(node cli.commander.js --help) <(node cli.js --help) && echo identical
identical

Same for count --help, both commands, a missing argument and a typo. Usage errors still exit 1; burgee's native exit 2 for "rewrite the command" does not come with the swap. Once commander leaves dependencies, the declared Node range goes from >=22.12.0 to ^20.19.0 || >=22.13.0. The swapped file ran on Node 20 and 22; only 22.12.x drops out.

What answers with no other edit

--schema: the command tree as data, a JSON Schema per command:

$ node cli.js --schema | jq -c '.commands[0].inputSchema'
{"type":"object","properties":{"file":{"type":"string","description":"file to read"},"skipBlank":{"type":"boolean","flag":"--skip-blank","description":"ignore empty lines"}},"required":["file"],"additionalProperties":false}

Errors under --json: typed, with the fix:

$ node cli.js count sample.txt --skp-blank --json
{"ok":false,"error":{"code":"commander.unknownOption","message":"unknown option '--skp-blank'","fix":"--skip-blank"}}

MCP discovery: every command becomes a tool, and an undeclared one says so instead of guessing a hint:

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node cli.js --mcp | jq -c '.result.tools[] | {name, annotations}'
{"name":"count","annotations":{"effects":"undeclared"}}
{"name":"longest","annotations":{"effects":"undeclared"}}

.effects("read_only") on count yields readOnlyHint: true. That call is a one-way door: real commander throws a TypeError.

Completions: completion <shell> for bash, zsh, fish, pwsh and fig, as static output.

Where one import stops

$ node cli.js count sample.txt --json
6 lines in sample.txt
{"ok":true,"data":null,"meta":{"provenance":{}}}

burgee's envelope wraps what an action returns. commander discards return values, so commander programs rarely write one. Under --mcp, that printed line lands on the JSON-RPC stream, where no client can parse it.

The second edit, in cli.answering.js: return the result, and keep prose off stdout when a machine asked:

+const machine = ["--json", "--mcp"].some((f) => process.argv.includes(f));
+const say = (text) => {
+  if (!machine) console.log(text);
+};
 ...
-    console.log(`${lines.length} lines in ${file}`);
+    say(`${lines.length} lines in ${file}`);
+    return { file, lines: lines.length };

$ node cli.answering.js count sample.txt --json
{"ok":true,"data":{"file":"sample.txt","lines":6},"meta":{"provenance":{}}}

Humans still see 6 lines in sample.txt. MCP tool calls get the same envelope. The argv test is crude. 0.11.1's façade has no public "machine asked?" flag yet.

Two defects, fixed in 0.11.1

Drafting on 0.9.2, I hit two defects in what the swap adds. An MCP call ignored the schema's "flag":"--skip-blank" and passed --skipBlank, which the program refused. Completions offered --no-skip-blank and --no-version, likewise refused. I fixed both in 0.11.1. The same call now answers:

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"count","arguments":{"file":"sample.txt","skipBlank":true}}}' | node cli.answering.js --mcp | jq -r '.result.content[0].text'
{"ok":true,"data":{"file":"sample.txt","lines":4},"meta":{"provenance":{"skipBlank":{"source":"flag"}}}}

Still open: an action's throw stays uncaught under --json.

What the grade covers

commander's own suite (v15.0.0, 110 files, unmodified) runs against burgee/commander next to a control on real commander. Re-run for this article: 1360 / 1360, control 1360 / 1360. That grade measures what you keep. The two defects sat in what you gain, which commander's tests cannot see.

When commander alone is the right size

On disk, commander 15.0.0 unpacks to 207,368 bytes; burgee 0.11.1 and the five sibling packages it installs, to 1,266,628. In a bundle, burgee's own lighter-than-commander gate measures not met, 1.524×. If no agent will call your CLI, commander is the smaller choice.

burgee vs commander · compatibility · source

Which command in your CLI prints something an agent currently scrapes with a regex, and what would returning it instead break?

A commander Stack Installs 70 Packages, burgee's Family 9. Like for Like, the Family Weighs 2.4 More.

Ofri Peretz — Wed, 23 Sep 2026 08:13:43 +0000

I maintain burgee, nine CLI packages, and counted them against the stack they replace, one usual package per layer:

npm i commander chalk ora inquirer string-width cosmiconfig execa signal-exit terminal-link

70 packages, maintained by 25 npm accounts. burgee's nine install 9 packages from 1 account.

That is the flattering row. Part 1 printed the rows against my plugins; same method, same rule here.

Layer by layer

Each incumbent is the first whole package in burgee's own "Replaces" column (the terminal row lists half of ansi-escapes first; with it, 66 packages), so the stack comes from my design surface, not a neutral sample. Resolved 2026-09-23, one package at a time; KB is 1,024 bytes of files, whole tree included.

incumbent	pkgs	KB	burgee family	pkgs	KB
commander@15.0.0	1	203	burgee@0.10.0	6	1169
chalk@6.0.0	1	55	roundel@0.4.3	1	76
ora@9.4.1	17	278	flagstaff@0.3.7	5	546
inquirer@14.2.2	27	1002	caique@0.4.3	3	302
string-width@8.2.2	4	36	linegauge@0.4.4	1	83
cosmiconfig@10.0.1	4	1789	seniority@0.4.3	1	149
execa@10.0.1	18	632	bellpull@0.2.3	1	96
signal-exit@4.1.0	1	75	closeout@0.4.1	1	100
terminal-link@5.0.0	6	60	paratext@0.5.4	1	91

On bytes, burgee's side is heavier in six of nine layers. Installed together, the incumbents weigh 3,851 KB; burgee, 1,577. The incumbent trees overlap (79 summed, 70 installed); burgee's overlap completely (20 summed, 9 installed).

Where that byte gap comes from

Three layers carry it, none cleanly.

cosmiconfig is 1,789 KB, and 1,702 of that is js-yaml and its argparse. seniority parses no YAML: it reads the JSON subset and refuses the rest by name. Against cosmiconfig's own test suite it passes 186 of 243.
execa has no graded drop-in. bellpull's compat row is cross-spawn, not execa.
inquirer is graded through @inquirer/core (41 of 41), not inquirer itself.

Keep only layers where burgee's drop-in scores what the incumbent scores on its own suite: commander, chalk, ora, @inquirer/core@12.0.3, string-width, signal-exit (not terminal-link: 8 of 10). 28 packages, 662 KB. burgee still installs all nine (sibling dependencies pull in the other three), 1,577 KB. Like for like, burgee is 2.4× heavier on disk, while the count stays 28 against 9, maintainers 14 against one.

The three gates burgee publishes as not met

burgee's README states nine gates; three fail their ≤ 1.0× target. I re-ran each with burgee's own fixtures:

gate	published	re-run
`burgee` bundle vs cac	2.636×	2.661×
`burgee/commander` bundle vs commander	1.514×	1.520×
cold start vs cac	1.443×	1.67–2.31×

The bundle rows agree within a percent. The cold-start re-runs, at load average above 80, read worse than burgee's published figure. Either way, not met. burgee's parity rows compare its bundles against cac, commander or yargs plus cosmiconfig, exit-hook and restore-cursor (0.282×, 0.468×, 0.531×). Those stacks include cosmiconfig, which my like-for-like rule excludes.

What "zero dependencies" means here

Six of nine declare no dependencies. burgee, flagstaff and caique depend only on those six: no dependency outside the family, which is not zero. burgee's README table says 0 runtime dependencies; the registry lists five, all siblings.

One account is also a concentration. Mid-measurement, my pipeline published burgee@0.10.0 at 05:34 UTC, then the closeout and linegauge it requires at 05:39 and 05:42; for eight minutes npm i burgee failed with ETARGET. And the family declares Node 24, where the incumbent stack's floor is Node 22.18. If you support Node 22.18, the incumbents are your option.

How to check yours

Part 1's method, plus bytes and maintainers:

cd "$(mktemp -d)" && npm init -y >/dev/null
npm i --package-lock-only <your dependencies>
node -e "console.log(Object.keys(require('./package-lock.json').packages).filter(k=>k.startsWith('node_modules/')).length)"
npm ci --ignore-scripts && node -e "let t=0;const f=require('fs'),w=d=>f.readdirSync(d,{withFileTypes:true}).forEach(e=>{const p=d+'/'+e.name;e.isDirectory()?e.name!=='.bin'&&w(p):e.isFile()&&e.name!=='.package-lock.json'&&(t+=f.statSync(p).size)});w('node_modules');console.log(t)"
node -e "const l=require('./package-lock.json').packages,m=new Set(),u=[];Promise.all(Object.keys(l).filter(k=>k.startsWith('node_modules/')).map(k=>fetch('https://registry.npmjs.org/'+k.split('node_modules/').pop().replace('/','%2F')).then(r=>r.ok?r.json():Promise.reject()).then(d=>(d.maintainers||[]).forEach(x=>m.add(x.name))).catch(()=>u.push(k)))).then(()=>console.log(m.size,'unfetched',u.length))"

Part 1 subtracted a 69-package ESLint baseline; here the shared baseline is Node, zero packages. pnpm, yarn 1 and bun resolve the same counts. The family ships often and its caret ranges float: pin all nine as tabled, or expect drift.

Run it on your CLI: how many npm accounts can ship code into your tree, and did you know that number before today?

[If the method earns a place in your release review, ⭐ star burgee.](https://ofriperetz.dev/go/gh/ofri-peretz/burgee?utm_source=devto&from=burgee-zero-dependency-cli-stack)

55 Places My Code Predates the Language. All Auto-Fixed.

Ofri Peretz — Wed, 23 Sep 2026 04:04:28 +0000

const latest = baseline[baseline.length - 1] ?? null;

Nothing is wrong with that line. It passes review, ships, and works. It is also how you wrote JavaScript before 2022, and I have written it a thousand times since.

I ran four modernization rules over 389 .ts/.tsx files across four of my own repos. 55 findings in 36 files — and every single one carried an autofix. After --fix, the remaining count was zero.

The two that fired

prefer-at — 11 findings. The end-of-array idiom, mechanically rewritten:

// before
const latest = baseline[baseline.length - 1] ?? null;
for (const a of accrual[accrual.length - 2].articles) {
  /* … */
}

// after --fix
const latest = baseline.at(-1) ?? null;
for (const a of accrual.at(-2).articles) {
  /* … */
}

prefer-template-literal — 44 findings:

// before
String(res.stderr || res.stdout || "claude exited " + res.status);

// after --fix
String(res.stderr || res.stdout || `claude exited ${res.status}`);

Why this survives review forever: a reviewer's job is to reject broken code, and none of this is broken. arr[arr.length - 1] is correct in every runtime that ever existed. The only thing that can flag it is a tool that knows what year it is.

The two that found nothing

no-instanceof-array and prefer-event-target returned 0 findings across all 389 files.

A rule that never fires is not broken — it is a rule for a pattern you do not have. instanceof Array breaks across realms; if you have never hit it, silence is correct. The failure mode to fear is the opposite: I have a rule elsewhere that flags every .map() in JSX, 476 findings of noise. Yield tells you nothing about quality on its own — the same trap as counting rules instead of measuring them.

Lint as codemod, not as style

Most lint rules ask you to decide something. These ask you to apply something — the semantics are identical and the fixer is exact.

You do not triage 55 findings — you run the fixer once, read the diff as one commit, and the rule holds the line. A migration plus a ratchet, the same shape as an autofix turning a hardcoded secret into a one-command repair.

Check the diff, though — "auto-fixable" means exact, not invisible, and there are two catches. .at() is typed at(index: number): T | undefined, while arr[arr.length - 2] is typed T, so a chained access can stop compiling: my accrual.at(-2).articles above is TS2532: Object is possibly 'undefined' under --strict. The ?? null on the first example absorbs it; a bare chain needs a guard. And .at() is ES2022 — Node 18+ and any 2023+ browser are fine, older targets need a polyfill.

The config

// eslint.config.mjs
import modernization from "eslint-plugin-modernization";

export default [
  {
    files: ["**/*.ts", "**/*.tsx"],
    plugins: { modernization },
    rules: {
      "modernization/prefer-at": "error",
      "modernization/prefer-template-literal": "error",
      "modernization/no-instanceof-array": "error",
      "modernization/prefer-event-target": "error",
    },
  },
];

npm  install --save-dev eslint-plugin-modernization   # npm
yarn add     --dev      eslint-plugin-modernization   # yarn
pnpm add     --save-dev eslint-plugin-modernization   # pnpm
bun  add     --dev      eslint-plugin-modernization   # bun

npx eslint . --fix

Measured against 3.1.2, peer range ^8.40.0 || ^9.0.0 || ^10.0.0, Node 18+. prefer-template-literal does not exist before 3.x, so an older install rejects the config. ESLint only.

All four at error is safe for these findings, but be precise why: in 3.1.2 only prefer-at and prefer-template-literal carry a fixer. All 55 findings came from those two, which is why --fix emptied the list — not because the plugin is 100% auto-fixable:

node -p "Object.entries(require('eslint-plugin-modernization').rules)
  .map(([k,r]) => k + ': ' + (r.meta.fixable || 'no fixer')).join('\n')"
# no-instanceof-array: no fixer
# prefer-at: code
# prefer-event-target: no fixer
# prefer-template-literal: code

Run it against the published package: a monorepo symlink resolves to unreleased source and answers a different question. prefer-event-target gains a fixer after 3.1.2.

Rule docs · npm.

Numbers measured 2026-08-12 against four repos I own — my code, not a public corpus, so treat 55 as a shape.

Re-run 2026-09-04 over the 189 .ts/.tsx files of this blog's public apps/blog/src, plugin at 3.1.2: 8 findings in 6 files — six prefer-at, two prefer-template-literal. Three weeks after the codemod, the old idiom had crept back eight times. That is the argument for leaving the rules at error.

Two guards on it. The harness reports unmatched: 0, so all 189 files were configured — an earlier run returned a confident 0 that was 189 files matching no config. And on that tree the same day, the noisy rule above returns 110: yield is not quality.

What's the oldest idiom still alive in your codebase — and is it there because it's correct, or because nothing ever flagged it?

My Benchmark Judged Five Models Against a Threshold Built for Three

Ofri Peretz — Thu, 17 Sep 2026 08:25:12 +0000

I went looking for a missing Bonferroni correction in my own benchmark. I found something worse on the way: the one significance test I did have was a dictionary.

const criticalValues = { 1: 3.841, 2: 5.991, 3: 7.815 };
const significant = chiSq > (criticalValues[df] || 5.991);

Three degrees of freedom in the table. Anything else falls through the || to 5.991 — the df=2 threshold. df here is models.length - 1, so the moment I compared five models, every verdict was measured against a bar meant for three.

Both predicates, on six statistics inside that gap:

χ²	df	old verdict	true p
7.0	4	significant	0.1359
8.0	4	significant	0.0916
9.0	4	significant	0.0611
7.0	5	significant	0.2206
10.0	5	significant	0.0752
12.0	6	significant	0.0620

Six for six — guaranteed: I chose points inside the gap. A probe shows the mechanism, not how often it fired. One of them has a true tail probability of 0.22 and the old predicate called it p < 0.05.

It fired once, and got the right answer

I went through every stored result. Eleven run files, three
of them carrying a chi-squared verdict, and exactly one lands in the gap:

{ "chiSquared": 18.43, "df": 4, "pValue": "< 0.05", "significant": true }

Judged against 5.991 instead of the 9.488 its four degrees of freedom
required. And it was right anyway — the true p is 0.001017, comfortably
significant on any threshold.

That is the whole problem in one row. The instrument was broken, the answer was
correct, and the output could not tell you which. A wrong method that returns
the right answer is not a near miss; it is a bug with no symptom — the kind
that stays.

The error had a direction

The table cannot make a real result disappear. The fallback is lower than every threshold it stands in for, so the mistake only ever converts noise into a finding. It never withholds one.

That asymmetry is the tell. A bug that fails randomly is a bug. A bug that fails exclusively in the direction that flatters your results is a bug you were never going to notice: every time it fired it told you what you hoped to hear.

Why it survived review

Because it looks like rigor. A table of critical values is textbook furniture, and the numbers are right — 3.841, 5.991 and 7.815 are correct for df 1, 2 and 3. Nothing in the diff is wrong. The defect is the || 5.991 — eight characters that turn "I don't know" into a confident answer.

It reads as harmless. I found the same function in a second runner where someone had already met this problem and fixed it — two more rows, 4: 9.488, 5: 11.07, behind the same || 5.991. The cliff moved from df≥4 to df≥6 and got harder to see, because the table looked more complete. Extending a lookup table is not fixing a lookup table.

The fix is arithmetic, not a bigger dictionary

The tail of a chi-squared distribution is a function. Compute it:

export function chiSquaredPValue(chiSq, df) {
  if (!(chiSq >= 0) || !(df >= 1)) return 1;
  return upperGamma(df / 2, chiSq / 2); // regularized incomplete gamma
}

That is the interface, not the implementation: upperGamma and a Lanczos log-gamma are not exported, so read it rather than paste it. It lives in benchmarks/lib/stats.ts on the branch carrying this fix (ofri-peretz/eslint#952), and npm --prefix benchmarks run stats:check runs it in a second. It reproduces 3.841, 5.991 and 7.815 to three decimals — and 9.488 and 11.07, which the table never had.

Then the check, which matters more than the fix. It asserts the rule, not the absence of one bad number: for a fixed statistic, more degrees of freedom must yield a larger p-value. That is the relationship the fallback inverted, so it fails loudly on the old code and passes on the new. A fix without a check that would have caught it is a fix you get to make twice.

The uncomfortable part is not that my benchmark had a bug. It is that the bug sat in the code for four months, judging every verdict against a bar meant for three, and the one time it mattered it agreed with me.

Foundations: what a p-value actually claims, statistical power, composite scores.

More of these — follow on dev.to.

If your own harness prints a p-value, did you check it was computed rather than looked up?

Your ESLint Plugin Installs 205 Packages. 69 Are ESLint.

Ofri Peretz — Sun, 13 Sep 2026 08:48:55 +0000

npm i -D eslint-plugin-import installs 205 packages.

That number is true and almost useless, which is the problem with every dependency-weight argument I have read. 69 of those packages are ESLint itself. Since npm 7, peer dependencies install automatically, so any plugin declaring eslint as a peer drags the entire linter into the count — and every plugin should declare it that way.

So I measured the baseline first, then subtracted it.

What each plugin actually adds

Resolved with npm install --package-lock-only into an empty project, one plugin at a time, on 2026-08-12. Bare eslint alone resolves to 69 packages — that is the zero point.

plugin	tree	adds	direct deps
eslint-plugin-import	205	136	19
eslint-plugin-react	204	135	18
eslint-plugin-jsx-a11y	194	125	15
eslint-plugin-unicorn	110	41	20
eslint-plugin-sonarjs	83	14	13
eslint-plugin-n	80	11	8
eslint-plugin-promise	70	1	1

Now look at the two columns on the right together, because they do not agree.

eslint-plugin-promise declares one direct dependency and adds one package. eslint-plugin-unicorn declares twenty and adds 41. eslint-plugin-sonarjs declares 13 and adds 14. But eslint-plugin-import declares 19 and adds 136 — seven per declared dependency, because its dependencies have dependencies.

Direct dependency count does not predict install weight. It is the number people quote, including me before I measured it, because it is the one visible on the npm page without resolving anything.

The number you actually install

Nobody installs one plugin. A conventional React setup:

npm i -D eslint eslint-plugin-react eslint-plugin-jsx-a11y eslint-plugin-import

228 packages. Not 69 + 135 + 125 + 136 — the trees overlap heavily and npm dedupes them, so the sum is far less than the parts. That is the other half of why per-plugin numbers mislead: they are neither additive nor independent.

Where mine land

I maintain a plugin suite, so here is my own row, measured identically:

plugin	tree	adds	direct deps
eslint-plugin-react-features	71	2	1
eslint-plugin-modernization	71	2	1
eslint-plugin-browser-security	71	2	1
eslint-plugin-import-next	97	28	2

Two packages: one shared internal toolkit, which itself has zero dependencies, plus the plugin. import-next adds 28 because it carries a real resolver — that is the trade it makes for being much faster.

I am not the leanest here and I want to be precise about that: eslint-plugin-promise adds one package and I add two. If dependency weight is your only axis, promise is the leaner choice.

One more honest reading of the table. eslint-plugin-security resolves to 3 packages total — the smallest number on this page by a wide margin. It does not declare eslint as a peer dependency at all, which is why the 69-package baseline never appears, and it is the plugin I have argued elsewhere is unmaintained. A small tree is not a proxy for a healthy package. It can just mean the package stopped changing.

How to check yours

mkdir /tmp/w && cd /tmp/w && npm init -y >/dev/null
npm i --package-lock-only <plugin>
node -e "console.log(Object.keys(require('./package-lock.json').packages).filter(k=>k.startsWith('node_modules/')).length)"

--package-lock-only resolves the graph without downloading anything, so it runs in about a second. Measure bare eslint first, subtract, and compare like with like. Then measure the union you actually install, because that is the only number that reaches your node_modules.

Every figure above was resolved on 2026-08-12 and will drift as these packages release. Re-run the four lines above rather than citing mine.

Re-run on 2026-09-04, all fourteen numbers on this page came back identical — the 69-package baseline, every plugin tree, and the 228-package combined install. Three weeks of ecosystem churn moved none of them, which is itself the finding: these trees are stable because the packages at the top of the table are not releasing.

Run it on your config — what's the gap between the packages you asked for and the packages you got?

[📦 npm i -D eslint-plugin-react-features — two packages, and you can check that number with the four lines above before you install it. If it earns its place in your CI, ⭐ star the repo.](https://ofriperetz.dev/go/npm/eslint-plugin-react-features?utm_source=devto&from=eslint-plugin-dependency-weight)

eslint-plugin-react-features is part of the Interlace ESLint ecosystem — every tree in the table above is measurable the same way. Source on GitHub · Follow: Dev.to/ofri-peretz

The 3 Most-Installed ESLint Plugins Went Quiet in 2025

Ofri Peretz — Sat, 12 Sep 2026 08:31:59 +0000

Pick the maintenance signal you can get in one second: days since the last release.

I pulled it from the npm registry for 18 ESLint plugins on 2026-08-12. The three with the deepest install base are the three that have gone quietest.

plugin	days since release	releases in 12mo
eslint-plugin-jsx-a11y	655	0
eslint-plugin-react	495	0
eslint-plugin-import	417	0
eslint-plugin-promise	107	1
eslint-plugin-security	61	2
eslint-plugin-sonarjs	28	9
eslint-plugin-unicorn	8	17
eslint-plugin-n	3	12
eslint-plugin-jest	0	35

Nine of the eighteen I measured shipped nothing at all in the last twelve months. Nearly two years of silence on the plugin that half the accessibility tooling in React depends on.

Dormant is not dead

Before drawing the obvious conclusion, the honest caveat: a plugin that stops releasing may simply be finished. jsx-a11y encodes WAI-ARIA rules. ARIA does not change every quarter. A stable spec produces a stable plugin, and "no releases" is the correct output for a package with nothing left to do.

So days-since-release is a prompt, not a verdict. Three signals actually separate finished from abandoned, and all three are free:

1. The npm deprecation flag. eslint-plugin-standard carries one. That is the maintainer telling you directly, and it is machine-readable — no interpretation required.

2. Supersession. eslint-plugin-node last shipped 2,328 days ago — over six years — because it was replaced by eslint-plugin-n, which shipped 3 days ago. One of those numbers is alarming and the other explains it. A rename is invisible to anyone reading only the old package's page.

3. Whether it still works on your ESLint. This is the one that matters and the one nobody checks until it breaks. A plugin frozen before flat config became the default is not "stable," it is on a countdown.

The genuinely dead tier

Sorted by silence, these are the ones where no reading rescues the number:

eslint-plugin-scanjs-rules      3,296 days   (9 years)
eslint-plugin-node              2,328 days   superseded by eslint-plugin-n
eslint-plugin-standard          2,088 days   npm-deprecated
eslint-plugin-flowtype          1,748 days   Flow itself receded
eslint-plugin-xss               1,507 days
eslint-plugin-security-node       951 days

Every one of these still installs cleanly today. npm will not warn you, your lockfile will not warn you, and a config that references them keeps passing — because a plugin whose rules never fire looks exactly like a codebase with no problems. That is the same failure shape as a CI check that was disabled rather than failing: silence reads as success.

The one that came back

eslint-plugin-security is the interesting row. It went 3.0.1 in June 2024 → nothing for 20 months → 4.0.0 in February 2026, and shipped again in June. If you had measured it in January you would have called it abandoned, correctly, and been wrong by March.

That is why a claim needs an expiry date rather than a verdict. "Unmaintained" is not a property of a package. It is a measurement with a date on it, and this one moved.

Measure your own config

Do not use time.modified for this. It is the obvious field and it is the wrong one: npm bumps it on any metadata change, so deprecating a package or transferring ownership makes a dead package look freshly touched. eslint-plugin-flowtype reports time.modified of 2026-01-24 — seven months ago, apparently maintained. Its last actual release was 2021-10-29. That is the 1,748-day row above, and the gap between the two fields is 1,548 days of false reassurance.

Read the publish date of the current version instead:

npm view <plugin> version                  # e.g. 8.0.3
npm view <plugin> time.8.0.3               # the date that version shipped

Or resolve the whole set at once:

node -e "for (const p of Object.keys(require('./package.json').devDependencies ?? {})) \
  fetch('https://registry.npmjs.org/'+p).then(r=>r.json()) \
    .then(j => console.log(p, j.time[j['dist-tags'].latest].slice(0,10)))"

Then apply the three checks above to anything past a year. Most will be fine. The point is knowing which ones you are betting on — eslint-plugin-import at 417 days is a dependency worth having an opinion about, given what it does on every lint run.

All figures resolved from the npm registry on 2026-08-12 and already drifting — eslint-plugin-jest was at 0 days when I measured it. Re-run the one-liner rather than citing mine.

Source at github.com/ofri-peretz/eslint · packages at npmjs.com/~ofriperetz · more at dev.to/ofri-peretz.

What's the oldest plugin in your lockfile — and did you know it before you looked?

ESLint Ships in 459 KB, So My Blog Posts Lint Your Code

Ofri Peretz — Wed, 02 Sep 2026 13:07:33 +0000

Every article about a lint rule has the same hole in it.

I paste a snippet, I paste the finding it produces. You think: fine, but does it fire on my code? The article cannot answer — it can only ever show you someone else's code.

So I shipped the linter instead. On the JWT article there is now a Try it live button: paste your own jwt.verify call and the published rule runs on it, in your browser.

The reason is a number I did not expect.

ESLint ships in 459 KB

eslint/universal exports the Linter class with no Node dependencies in its public surface: you hand it source text and a flat config, it hands you messages back.

It is a hard floor, not a polyfill: the ./universal export first appears in ESLint 9.11.0. ESLint 9.10 and every ESLint 8 resolve it to nothing, so this recipe does not degrade on older majors — it fails at build time.

With two real security plugins bundled inside it:

	bytes
raw bundle	1,764,382
`brotli -q 11` locally	370,746
what the CDN actually sends	470,563

Quote the last row, not the second. I first published 362 KB, having confirmed content-encoding: br — which proves the encoding, not the size. The CDN compresses on the fly below -q 11, so the honest number is 459 KB. Same artifact byte for byte; only the compressor differs.

Still the whole argument. At several megabytes you write a blog post about the rule. At 459 KB you ship the rule.

The recipe

The worker holds the linter and never talks to a server:

import { Linter } from "eslint/universal";
import jwt from "eslint-plugin-jwt";

const PLUGINS = { jwt }; // enumerated, never dynamic
const linter = new Linter();

self.onmessage = ({ data: { id, code, pluginId, rules } }) => {
  const findings = linter.verify(code, {
    plugins: { [pluginId]: PLUGINS[pluginId] },
    languageOptions: { ecmaVersion: 2024, sourceType: "module" },
    rules,
  });
  self.postMessage({ id, findings }); // no network, ever
};

The build step is where the real work is — aliases and a banner:

buildSync({
  entryPoints: ["src/workers/lint.worker.ts"],
  outfile: "public/lint-worker.js",
  bundle: true,
  minify: true,
  format: "iife",
  platform: "browser",
  // A worker global has no `process`. ESLint touches more of it than
  // NODE_ENV — cwd, platform, emitWarning — so stub it in a banner.
  banner: {
    js:
      'var process={env:{NODE_ENV:"production"},' +
      'platform:"browser",cwd:function(){return "/"},argv:[]};',
  },
  alias: {
    path: "path-browserify",
    "node:path": "path-browserify",
    fs: shims,
    os: shims,
    util: shims,
    // If anything in your graph pulls oxc-resolver, its native
    // bindings ride in and break the build. Rules never touch it.
    "oxc-resolver": shims,
  },
});

shims is a no-op Proxy, imported but never exercised.

The client seam is a lazy worker. The part worth copying is the failure path:

worker.onerror = () => {
  worker?.terminate();
  worker = null; // ← this line
  for (const entry of pending.values())
    entry.reject(new Error("worker failed"));
};

Nulling the singleton separates a playground that self-heals from one dead until reload. Without it every later lint posts into a corpse and the UI shows a clean result forever: "no findings" and "the analyzer is dead" look identical. So the surface renders "unknown, not clean" on failure, never an empty list.

Three traps

Don't let your framework bundle it. Asking Next.js to build the worker means teaching both webpack and Turbopack about node: schemes: two fragile configs for one artifact. Use esbuild yourself.

A real worker has no process. My spike ran under Node so ReferenceError: process is not defined only appeared in the browser. A spike passing is not the thing working.

Linting the artifact will OOM your editor. ESLint tried to lint the 1.7 MB bundle and died with Abort trap: 6: heap exhaustion, not a native crash. Add public/** to globalIgnores.

Try it

Both run published npm packages, the tarballs npm install gives you:

JWT alg:none — remove "none" from the algorithms array, watch the finding clear.
node-security — three rules on an upload handler.

Nothing you type leaves the page — and the UI says so in as many words, because pasting auth code into a stranger's site deserves an explicit answer rather than an assumption.

Reproduce it

Measured 2026-09-03 against eslint 9.39.4, eslint-plugin-jwt 2.2.14, eslint-plugin-node-security 5.2.3, esbuild 0.28.2, on Node 24.18. The build step itself inherits ESLint's floor, ^18.18.0 || ^20.9.0 || >=21.1.0 — there is no Oxlint variant of this recipe, because eslint/universal is ESLint's own export.

# from the repo root
node apps/blog/scripts/build-lint-worker.mjs
wc -c < apps/blog/public/lint-worker.js                  # 1764382
brotli -q 11 -c apps/blog/public/lint-worker.js | wc -c  # 370746
# what a reader actually downloads — measure this one, not the line above
curl -s -H 'Accept-Encoding: br' https://ofriperetz.dev/lint-worker.js | wc -c   # 470563

Those bytes drift as plugins ship rules; quote them with a date.

Browser-hosted linting is not new; ESLint and typescript-eslint both run excellent playgrounds. What is unusual is placement: not a destination you navigate to, but the rule the paragraph is arguing, running on your code, at the moment you wonder about it.

⭐ Star the repo if you have ever wanted docs that run instead of assert.

I Ran My Plugins Against a Competitor's Own Test Suite

Ofri Peretz — Tue, 01 Sep 2026 06:07:09 +0000

Every "we replace X" claim in the linting space is unfalsifiable, including the ones I have made. The competitor's rules are a list on a README, so comparison collapses into counting rule names.

But eslint-plugin-security ships its test suite inside the npm tarball. That is a corpus: 84 code samples its authors wrote specifically to be caught — and a corpus someone else wrote is the only kind that can embarrass you, which is the whole problem with benchmarking your own tool.

So I stopped counting rules and ran their tests against my plugins.

The method

Their tests use ESLint's RuleTester. Rather than parse samples out of the source, intercept the runner and collect them:

const { RuleTester } = require("eslint");
const captured = [];
RuleTester.prototype.run = (name, rule, tests) => {
  for (const t of tests.invalid ?? []) captured.push(t.code ?? t);
};
for (const f of fs.readdirSync("node_modules/eslint-plugin-security/test/rules"))
  require(`.../test/rules/${f}`);

84 samples. Then lint each one twice — once with their plugin, once with mine — and count which ones produce at least one finding.

The result

	flags
eslint-plugin-security (on its own tests)	71 / 84
my plugins	51 / 84

They win, and the honest headline is that I cover 61% of their corpus. But the distribution matters more than the total, because 29 of my 33 misses are a single rule:

 29  detect-buffer-noassert
  1  detect-disable-mustache-escape
  1  detect-no-csrf-before-method-override
  1  detect-pseudoRandomBytes
  1  detect-unsafe-regex

Excluding that one rule, it is 51 of 55 — 93%.

The obsolete rule

detect-buffer-noassert flags buf.readUInt8(0, true). The noAssert argument told Node.js to skip offset validation, so a read could run past the end of the buffer.

It was removed in Node 10. On Node 24:

const b = Buffer.alloc(4);
b.readUInt8(0, true);   // extra argument ignored
b.readUInt8(99);        // still throws ERR_OUT_OF_RANGE

The parameter has done nothing for about seven years. Their rule still ships in recommended, and their suite tests it across 29 variants — every read* method — which is why one dead rule dominates the gap.

I am not claiming that is wrong of them. Removing a rule breaks configs, and the cost of keeping it is nearly zero. But it is the difference between "61% coverage" and "93% coverage of everything that can still bite you," and no rule-name comparison would ever surface it.

What I catch that they miss

The reverse direction is the part I did not expect. Running their corpus through their own plugin leaves 13 samples unflagged, and my rules catch all 13:

  9  detect-non-literal-fs-filename
  4  detect-child-process

Those are their test cases, written for their rules, that their current implementation does not fire on. Combined, the two plugins flag 84 of 84 — every sample is caught by someone.

Where I lose

Corpus coverage is one criterion and it is the flattering one, so here is the criterion that is not.

On their curated samples my precision looks excellent, because every sample is a real vulnerability. Pointed at ordinary code, it is a different story: I ran my Node rules over 61 files of my own automation scripts last week and got 279 findings, and every one I inspected was a false positive — a timing-attack warning on if (key === -1), a zip-slip warning on a string literal. I have open fixes for those. A corpus benchmark cannot see them, because a corpus contains no boring code.

Coverage and precision are different measurements, and a test suite only measures the first. Anyone quoting one number at you is quoting the one that flatters them — that is measurement bias with a marketing budget. I just did it too: 93% is the number I would put on a slide.

Run it yourself

The whole thing is about 40 lines and no AI, no benchmark harness, no service. Any plugin that ships its tests can be measured this way, in both directions, in a few minutes.

Point it at mine: eslint-plugin-node-security ships its tests too, and I would rather read your numbers than my own.

npm install -D eslint-plugin-node-security

Measured 2026-08-12 against eslint-plugin-security 4.0.1 on ESLint 9.39.2, with my plugins under @typescript-eslint/parser (they are TypeScript-native; the default parser under-reports them by 13 samples). Related: what ground truth caught that unit tests missed, and the maintenance question about this same plugin.

Source at github.com/ofri-peretz/eslint · packages at npmjs.com/~ofriperetz · more at dev.to/ofri-peretz.

If someone ran your test suite against a competitor, what would it show?

My 9-Reviewer AI Gate Failed Articles It Scored 9.1

Ofri Peretz — Wed, 26 Aug 2026 00:01:20 +0000

Nine LLM reviewers score every article I publish. The gate is simple: zero blockers, and a mean score above my floor.

Yesterday it failed an article it had scored 9.1. Then it failed a second one three separate times. Neither reviewer ever disagreed with the writing — all three failures were the harness misreading its own reviewers.

A perfect score, filed as a blocker

The Checklist reviewer returned 10.0 and wrote this under BLOCKERS:

no biography/family/military/location/heritage; no political position;
the numbers are incident/operational facts, so the rule doesn't bite.

That is a clean bill of health. It failed the gate.

The parser dropped lines meaning "nothing here" with /^none/i. The prompt asks reviewers to explain why nothing is wrong, so they write the explanation instead of the word — and "no biography" is not "none".

Why it survives review: the regex is correct for the string it was written against. Nobody writes a test for the sentence a model didn't emit.

The fix wasn't a longer regex. Guessing every phrasing of "nothing is wrong" is unbounded. The prompts already state the contract — fully in scope means BLOCKERS: None and SCORE: 10 — so a 10 that also reports a blocker is self-contradictory:

if (score === 10 && blockers.length) {
  improvements.push(...blockers);  // demote, never drop
  blockers = [];
}

Demoted, not deleted. If a reviewer ever scores 10 on something genuinely broken, the text still reaches a human.

The word that made good reviews look like outages

My runner treats a quota message as a transport failure, so a billing error can never be scored as a bad article. The pattern included a bare rate limit.

It was tested against the reviewer's entire output. My corpus is security articles. Reviewers say "rate limit" constantly:

· Discovery & Hook: USAGE LIMIT — SCORE: 8.0
· Voice & Agenda:   USAGE LIMIT — SCORE: 9.5
· Quality:          USAGE LIMIT — SCORE: 9.0

Three finished reviews, scores visible in the text that got thrown away. That article lost 4 of 9 reviewers and failed two batch runs before I looked. It reads as an account problem, which is exactly why it survived.

The tell separates the two cleanly: a real quota banner is the only thing on stdout. A review that merely discusses limits has a SCORE: line sitting right there.

An excluded reviewer voting anyway

One reviewer is informational — its rubric weights brand fit 40%, which structurally caps anything outside that niche. It was excluded from the gate score.

It was not excluded from blockers. So it vetoed through the back door — and what it files under BLOCKERS is its own arithmetic:

✗ Axis 1 — Content Quality: 8.5
✗ Weighted = 8.5 x 0.6 + 5 x 0.4 = 7.1

Four "blockers" on an article it had just called original and reproducible. A half-applied exclusion is not an exclusion — and a weighted composite is exactly the shape that hides one, because the arithmetic looks like a finding.

The pattern

Every one of these is the harness misreading agreement as disagreement, and all three fail in the same direction: quietly, toward rejection. A false pass is loud — something bad ships and you see it. A false fail looks exactly like a strict gate doing its job, so it can run for weeks while you assume the work is merely not good enough yet. It is the same asymmetry that makes a leaderboard wrong in the flattering direction, and the same reason measurement bias survives longest when it agrees with what you expected.

If you run an LLM as a judge, assert on the disagreements it cannot logically have: a perfect score with a blocker, a reviewer excluded from the score that still blocks, a transport error carrying a parsed result. Those are contradictions, and contradictions are testable without predicting a single word the model will say.

assert.equal(parse("SCORE: 10\nBLOCKERS:\n- none found here").blockers.length, 0);
assert.equal(parse("SCORE: 7\nBLOCKERS:\n- the claim has no date").blockers.length, 1);

Both directions. A one-sided test would have passed on all three bugs — my earlier fix for the opposite failure is what introduced the second one. That is the same lesson ground truth taught me that unit tests could not: a test written from the failure you already know about only ever proves you fixed that one.

More on the tooling behind this at github.com/ofri-peretz/eslint. The three defects above were found on 2026-08-11 across 39 gated articles.

What's the last false negative you found in your own tooling — and how long had it been running?

I Linted My Own Design System. All 8 Breaks Were Pasted In.

Ofri Peretz — Thu, 20 Aug 2026 09:23:07 +0000

Your design system has tokens. Your linter does not know they exist.

eslint-plugin-react has 104 rules and not one of them can tell you that #ffffff1f should have been var(--surface-highlight). That gap is invisible in review, because a hex value in a className looks exactly like every other string.

So I ran four rules over my own code: 401 .tsx files across a design system, a docs site, a blog, and a control-room app. 144 violations in 50 files. The design system defines 192 tokens. It also breaks them.

Raw color literals: 30 findings, and they cluster

The rule is no-raw-color-literal — any hex, rgb(), or rgba() in JSX source.

// packages/ui/src/effects/shimmer-button.tsx:102
"rounded-2xl px-4 py-1.5 text-sm font-medium shadow-[inset_0_-8px_10px_#ffffff1f]"

⚠️ Raw color literal in source — use a design token (R19) | MEDIUM
 Fix: Replace with a CSS custom property (var(--your-token)) or a Tailwind
      theme class wired to it.

Why this survives review: the hex is inside an arbitrary Tailwind value inside a class string. A reviewer scanning for color changes greps for color or bg-. Nobody greps for #.

Here is the part I did not expect. The design system package had 8 of these, and all 8 were in ambient/, effects/, and patterns/ — components I pasted in from component galleries. The core primitives had zero.

The system didn't drift. It leaked at the seam where other people's code came in.

`data-slot`: 67 findings, the biggest by far

⚠️ JSX element has data-testid but no data-slot (R6) | MEDIUM

require-data-slot fires when an element carries a data-testid but no data-slot. Both are hooks; only one is a contract. A data-testid says "a test grabs this." A data-slot says "consumers may style this." Ship the first without the second and every consumer targets your test IDs, and your next refactor breaks their CSS.

67 of my 144 findings were this one rule. It is the least dramatic and the most expensive — a data-testid standing in for a styling contract is a proxy metric with a refactor bill attached.

The pattern

A design system fails at its boundaries, not its center. The primitives I wrote while thinking about tokens obey them. The components I imported while thinking about shipping do not — and they arrive pre-broken, which means no diff ever shows the moment the violation entered.

That is why this has to be a lint rule and not a review convention. Review catches what a diff shows. Pasted code shows up as one clean green addition.

The config

// eslint.config.mjs
import reactFeatures from "eslint-plugin-react-features";

export default [
  {
    files: ["**/*.tsx"],
    plugins: { "react-features": reactFeatures },
    rules: {
      "react-features/no-raw-color-literal": "error",
      "react-features/no-arbitrary-token-class": "error",
      "react-features/require-data-slot": "warn",
      "react-features/no-inline-style": "warn",
    },
  },
];

npm i -D eslint-plugin-react-features

eslint-plugin-react-features on npm · all four rule docs

Start the last two at warn. On a codebase that has never had these rules, require-data-slot alone will be your largest number, and turning it red on day one just teaches people to disable it.

An honest caveat: 47 of this plugin's 61 rules overlap eslint-plugin-react by name. These four do not — nothing in the incumbent enforces a token system, because the incumbent cannot know what your tokens are.

Source at github.com/ofri-peretz/eslint. Every number here came from a run on 2026-08-11 against the four repos named above — four repos I own, which is a sample of one opinion about components, not a ground-truth corpus. I ran my own rule over my own code and reported what it found, which is the only version of benchmarking I trust myself to do. Re-run it on yours and you will get different numbers.

Run one of these on your own components — what's your data-slot number? Mine was 67, and I wrote the rule.

Your Token Is Not Safer in a Cookie. It Is Safer From JavaScript.

Ofri Peretz — Fri, 14 Aug 2026 09:43:04 +0000

Every team I have worked on has had the localStorage argument. Someone says tokens belong
in cookies. Someone else says cookies mean CSRF. Both cite a blog post. The token stays
where it was.

The argument is unwinnable as stated, because both sides are describing the container —
and the container is not what decides the outcome.

The axis everyone argues about

Ask why one mechanism is safer and you get answers about persistence, capacity, expiry,
whether it survives a tab close. Real differences. None of them has anything to do with an
attacker.

The axis that decides it

One question: can JavaScript running on your origin read it?

If yes, anything achieving script execution on your page reads it too. Not encryption —
you have nowhere to put the key. Not obfuscation — the attacker has your bundle. Not "we
only write it after login" — the attacker runs after login too.

Mechanism	Readable by page JS	Under XSS
`localStorage`	yes	gone
`sessionStorage`	yes	gone
IndexedDB	yes	gone
Cache API	yes	gone
Cookie without `HttpOnly`	yes	gone
Cookie with `HttpOnly`	no	survives

Five of those six rows are the same row. The debate spends its energy on a distinction
that exists only in the last line — and it is not the cookie that creates it, it is the
flag.

`HttpOnly` is the boundary

HttpOnly is unusual: a capability the browser withholds from your own code. You cannot
opt back in at runtime. No API reads it, no devtools trick your bundle can perform. The
value goes out on requests to its domain and is otherwise unreachable.

Almost nothing else in the browser works this way. Everything in the first five rows is a
filing cabinet in a public lobby — useful, convenient, not a vault, and never described as
one by anyone who built it.

The corollary people skip

HttpOnly protects the token from being read. It does not stop it being used.

Script on your origin can still fetch with credentials: "include", and the browser
attaches the cookie. The attacker does not hold your session; they operate it, from your
page, while it is open. Smaller blast radius — no exfiltration, no replay next week — but
not nothing.

The honest summary: HttpOnly converts permanent theft into temporary misuse. Real
and worthwhile. Not immunity.

So what counts as sensitive

Stop asking "is this sensitive" — a word that invites negotiation. Ask: if an attacker
had this value, what could they do, and for how long?

Session token — act as the user until expiry.
Refresh token — mint new sessions, far longer. Higher risk, and the one most often parked in localStorage because it needs to persist.
Cached API response with personal data — disclosure, not takeover. The Cache API is the mechanism people forget is storage at all.
Feature flag, theme, draft — nothing. Put it anywhere.

And the CSRF half?

Never on the same axis either. CSRF is the browser attaching a cookie to a request the
user did not intend — a property of ambient authority, not storage — and SameSite
addresses it directly.

That is why the debate feels unresolvable: one camp describes a read primitive, the other
a send primitive. HttpOnly answers the first, SameSite the second — orthogonal flags on
the same cookie.

Where this lands in the standards

Reading storage you should not have access to is
CWE-522 — insufficiently protected
credentials — under
A07:2021.
HttpOnly and Secure are specified in
RFC 6265 §4.1.2.5–6;
SameSite arrived later, in
RFC 6265bis, still
a draft despite universal implementation. Both are on
MDN's Set-Cookie page.
For severity language, use
CVSS and
the OWASP categories.

Why the argument keeps happening

All five equivalent rows are reached the same way: script execution on your origin. So
storage is downstream of the XSS question, and a team that has not settled how untrusted
data reaches a DOM sink is arguing about where to put the token while leaving the door
open. DOM sinks and sources, the
companion piece in this series, works through why those sources outnumber the sinks.

What is in your localStorage right now? Not what you think — open devtools and look. I
have found a refresh token, a full user object with an email, and a cached permissions
array in codebases I would have defended.

I write about measurement and static analysis at
dev.to/ofri-peretz.

DEV Community: Ofri Peretz

Everyone Greps for SQL Injection. Nobody Greps for the Other Eight.

The shape, not the syntax

Three that fail in ways SQL does not

Why grep finds SQL and misses the rest

What to actually do

One Import Moves a commander CLI to burgee. --json Still Says null.

The program

The swap

What answers with no other edit

Where one import stops

Two defects, fixed in 0.11.1

What the grade covers

When commander alone is the right size

A commander Stack Installs 70 Packages, burgee's Family 9. Like for Like, the Family Weighs 2.4 More.

Layer by layer

Where that byte gap comes from

The three gates burgee publishes as not met

What "zero dependencies" means here

How to check yours

55 Places My Code Predates the Language. All Auto-Fixed.

The two that fired

The two that found nothing

Lint as codemod, not as style

The config

My Benchmark Judged Five Models Against a Threshold Built for Three

It fired once, and got the right answer

The error had a direction

Why it survived review

The fix is arithmetic, not a bigger dictionary

Your ESLint Plugin Installs 205 Packages. 69 Are ESLint.

What each plugin actually adds

The number you actually install

Where mine land

How to check yours

The 3 Most-Installed ESLint Plugins Went Quiet in 2025

Dormant is not dead

The genuinely dead tier

The one that came back

Measure your own config

ESLint Ships in 459 KB, So My Blog Posts Lint Your Code

ESLint ships in 459 KB

The recipe

Three traps

Try it

Reproduce it

I Ran My Plugins Against a Competitor's Own Test Suite

The method

The result

The obsolete rule

What I catch that they miss

Where I lose

Run it yourself

My 9-Reviewer AI Gate Failed Articles It Scored 9.1

A perfect score, filed as a blocker

The word that made good reviews look like outages

An excluded reviewer voting anyway

The pattern

I Linted My Own Design System. All 8 Breaks Were Pasted In.

Raw color literals: 30 findings, and they cluster

data-slot: 67 findings, the biggest by far

The pattern

The config

Your Token Is Not Safer in a Cookie. It Is Safer From JavaScript.

The axis everyone argues about

The axis that decides it

HttpOnly is the boundary

The corollary people skip

So what counts as sensitive

And the CSRF half?

Where this lands in the standards

Why the argument keeps happening

`data-slot`: 67 findings, the biggest by far

`HttpOnly` is the boundary