Fix SQL Injection (Legacy & Modern) in RedwoodJS

RedwoodJS abstracts the database layer via Prisma, but developers often bypass the ORM for performance or complex joins, introducing SQL Injection (SQLi) vulnerabilities. In a Redwood environment, the threat vector is almost always the misuse of Prisma's raw query methods. If you are concatenating strings in `$queryRawUnsafe`, you are leaving the door wide open for data exfiltration and unauthorized access.

The Vulnerable Pattern

export const getPostBySlug = ({ slug }) => {
  // CRITICAL VULNERABILITY: String interpolation in queryRawUnsafe
  // Attacker can pass: "' OR 1=1 --"
  return db.$queryRawUnsafe(
    `SELECT * FROM "Post" WHERE slug = '${slug}'`
  )
}

The Secure Implementation

The vulnerability stems from `$queryRawUnsafe`, which executes a raw string without any sanitization. By injecting SQL control characters, an attacker can manipulate the query logic. The fix is to use `$queryRaw` with ES6 tagged template literals. Prisma's engine intercepts these templates, extracts the variables, and sends them to the database as bound parameters (prepared statements). This ensures that the database engine treats the input strictly as data, never as executable code. If your query must be dynamically generated, always use positional placeholders ($1, $2) and pass the values as secondary arguments to ensure parameterization.

export const getPostBySlug = ({ slug }) => {
  // MODERN FIX: Use Prisma Tagged Templates
  // Prisma automatically parameterizes variables in $queryRaw
  return db.$queryRaw`SELECT * FROM "Post" WHERE slug = ${slug}`
// LEGACY/DYNAMIC FIX: Use parameterized arguments with queryRawUnsafe
// return db.$queryRawUnsafe(‘SELECT * FROM “Post” WHERE slug = $1’, slug)
}