All user-facing queries use parameterized inputs (no string interpolation)

SQL injection via string interpolation is OWASP A03 and CWE-89, and it remains the most exploited database vulnerability in production applications. A single unparameterized query — `SELECT * FROM users WHERE email = '${email}'` — lets an attacker bypass authentication, extract all rows, or drop tables by submitting crafted input. AI-generated code frequently uses template literals for readability without recognizing the injection risk. Even one unparameterized query with user input is a critical vulnerability regardless of how many other queries are safe, because an attacker will find and exploit that one path.

Replace all string interpolation in SQL with parameterized placeholders. For pg, use $1/$2 positional parameters. For Prisma raw queries, use the Prisma.sql tagged template — never $queryRawUnsafe with user input.

// VULNERABLE — never do this
// const q = `SELECT * FROM users WHERE email = '${email}'`

// SAFE — pg parameterized query
const { rows } = await pool.query(
  'SELECT id, email, name FROM users WHERE email = $1',
  [email]
)

// SAFE — Prisma raw with tagged template
const users = await prisma.$queryRaw(
  Prisma.sql`SELECT * FROM users WHERE email = ${email}`
)

Search for gaps: grep -rn '\$queryRawUnsafe\|sql\.*${' src/ to surface candidates. ORM query builder methods (.where(), .findMany()`) are safe by default — scrutiny is only needed for raw SQL.