Fix sQL query built by string interpolation in Next.js

A SQL string is assembled with a template literal or concatenation and passed to a database driver. Any value interpolated into it is executed as SQL, so a request parameter can read, modify, or destroy data the query was never meant to touch. Use the driver's parameter binding instead; every driver has it.

high likely Next.js CWE-89 / OWASP A03:2021

The vulnerable pattern in Next.js

HIGH likely SQL query built by string interpolation A03:2021 app/api/login/route.ts:16:5 14 │ // sql-injection 15 │ const rows = await pool.query( 16 │ `SELECT id, role FROM users WHERE email = '${body.email}'`, │ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ query text is built at runtime 17 │ )

This finding comes from the Next.js fixture in the owlwarden test suite, in /api/login. A value taken from the request is interpolated into SQL, so the caller controls part of the statement. That is enough to read other users' rows, bypass a WHERE clause, or drop a table.

The corrected handler

Use a parameterised query, or Prisma's tagged $queryRaw which binds automatically.

// node-postgres
await db.query('SELECT * FROM users WHERE id = $1', [id])

// Prisma: the tagged form binds; $queryRawUnsafe does not
await prisma.$queryRaw`SELECT * FROM users WHERE id = ${id}`

If you are not using Next.js

Pass the values as query parameters instead of interpolating them. Every driver supports it, and the binding is not optional formatting - it is what stops the value being parsed as SQL.

Check your own repository

npx owlwarden scan
npx owlwarden explain sql-injection

Runs on your machine. No account, no telemetry, no network unless you ask. In CI, SARIF uploads to code scanning and the exit code is the gate.

Other Next.js checks

Rules with a tested Next.js example.

sql-injection for every framework / All rules / owlwarden