如何防止Prisma原生SQL查询被注入-SQL-PHP中文网

$queryrawunsafe 绝对不可用于用户输入，因其不解析、不转义、不参数化；唯一安全路径是 $queryraw 配合 prisma.sql 模板字面量实现参数化，且须严格区分数据（用 ${...}）与结构（需白名单校验）。

如何防止prisma原生sql查询被注入

$queryRaw 和 $queryRawUnsafe 是 Prisma 中唯一直接执行原生 SQL 的入口，也是注入风险的唯一出口。只要用了 $queryRawUnsafe，就等于主动放弃所有防护——它不解析、不转义、不参数化，传进去的字符串原样交给数据库执行。

为什么 `$queryRawUnsafe` 一定不能碰用户输入

它设计初衷是执行完全可控的静态 SQL（比如建表语句、迁移脚本），而非动态查询。$queryRawUnsafe 不做任何参数绑定，连 -- 或 # 注释符都照常生效。一旦拼接用户输入，攻击者就能用 1 OR 1=1 -- 或 1'; DROP TABLE users; -- 直接击穿。

错误示例：prisma.$queryRawUnsafe(`SELECT * FROM users WHERE id = ${req.query.id}`)
哪怕加了 parseInt()，只要没严格校验范围或类型，仍可能被绕过（如 id=1.0 在某些驱动里仍被接受）
$queryRawUnsafe 的返回值也不做类型检查，错误 SQL 可能静默失败或返回意外结构

`$queryRaw` + `Prisma.sql` 是唯一安全路径

$queryRaw 本身不危险，真正起作用的是 Prisma.sql 模板字面量——它把 SQL 字符串和参数分离，交由底层驱动做预编译处理，等效于 PreparedStatement。

正确写法：prisma.$queryRaw`SELECT * FROM users WHERE id = ${parseInt(req.query.id) || 1}`
参数必须用 ${...} 插入，且仅支持标量（number/string/boolean/Date）或 Prisma 类型（如 Prisma.Decimal）
不能在模板字符串里拼接变量名或表名，例如 `SELECT * FROM ${tableName}` 是非法且不安全的
聚合排序等复杂场景（如按嵌套评论总数排序）必须走这条路，否则无法绕过 Prisma 原生限制

哪些地方容易误用字符串拼接

开发者常在“以为安全”的地方翻车：动态字段名、ORDER BY 子句、LIMIT 值、UNION 查询分支。这些都不能靠 ${...} 参数化，因为 SQL 解析器需要它们是语法结构的一部分，而非数据。

字段名/表名：必须白名单校验后硬编码，或用 Prisma 的 select / include 替代
ORDER BY：用 if 分支预定义合法排序项，如 req.query.sort === 'name' ? `ORDER BY name` : `ORDER BY id`
LIMIT/OFFSET：只接受数字，且需 Math.min() 限流（如最大 100 条），再传入 ${limit}
UNION：每个子查询独立用 Prisma.sql 构造，禁止拼接整个 UNION 字符串