Articles

Direct concatenation, template literal injection, and dynamic identifier injection: three structurally distinct SQL injection surfaces in node-postgres codebases. Why each survives code review, why AI assistants regenerate all three — across a 700-function benchmark, database queries were the worst domain for every Claude and Gemini model — and which ESLint rules catch them statically, no matter who or what wrote the line.

One user-controlled COPY FROM path turns your database into a file reader for /etc/passwd, your .env, and SSH keys. Here is why it survives code review, why AI assistants reintroduce it, and the one ESLint rule that tiers and blocks it.

A for-loop with an INSERT inside turned a 100ms bulk write into 50 seconds — 500x slower at 1,000 rows. The post-mortem, a reproduction you can run in 60 seconds, and pg/no-batch-insert-loop (CWE-1049): the ESLint rule that catches the N+1 shape before it ships.

Control a connection's search_path and every unqualified query silently resolves to your schema. The obscure-but-lethal PostgreSQL attack, why SET can't be parameterized, the real fixes, and the CWE-426 ESLint rule that catches it.

SQL injection is the famous node-postgres failure — but identifier hijacking, connection-pool exhaustion, and insecure transport page you at 3 AM just as hard. The four data-layer threat classes, the pg-specific ESLint rule for each, the one config that turns them all on — and why AI assistants get the database layer wrong (Gemini 2.5 Pro: up to 96% flagged in the database domain).