Knex 默认通过参数化查询防止SQL注入，但仅限原生方法；使用knex.raw()或动态表名/排序字段时需白名单校验。
Knex 本身不提供 SQL 注入防护，安全与否完全取决于你如何构造查询——它只是把 JS 链式调用翻译成 SQL，不会自动转义或拦截危险输入。
为什么 knex('users').where('name', req.query.name) 是安全的
Knex 默认使用参数化查询（prepared statement），所有 where、insert、update 等方法传入的值都会被绑定为 bindings，不拼接进 SQL 字符串：
knex('users').where('name', 'O\'Reilly').toSQL()
// → { sql: 'select * from "users" where "name" = ?', bindings: ["O'Reilly"] }- 单引号、分号、
UNION SELECT全部被当作文本值，不会执行 - 仅限 Knex 原生方法（
.where()、.whereIn()、.join()等）才启用该机制 - 一旦你用
knex.raw()拼接用户输入，立刻失去保护
哪些操作会绕过参数化，必须手动过滤
以下写法等同于直接执行字符串，req.query.table 或 req.body.orderBy 若未校验，就会触发 SQL 注入：
-
knex.raw('SELECT * FROM ?? WHERE id = ?', [req.query.table, req.query.id])——??只允许白名单表名/字段名，不能填任意字符串 -
knex('users').orderBy(req.query.orderBy)——orderBy接受字符串，但若传入"id; DROP TABLE users"会原样输出 -
knex.raw(`SELECT * FROM ${req.query.table}`)—— 绝对禁止，连基础替换都没做
正确做法是：用白名单严格限制动态部分
const allowedTables = ['users', 'posts', 'comments'];
const table = allowedTables.includes(req.query.table) ? req.query.table : 'users';
<p>const allowedOrders = { created_at: 'created_at', name: 'name' };
const order = allowedOrders[req.query.orderBy] || 'created_at';</p><p>knex(table).orderBy(order)在 Koa 中封装安全的查询中间件
不要让每个 controller 自己判断字段合法性。把校验逻辑下沉到统一层：
OpenGemini Next.js Bestpractice Builder
下载
使用固定的 Next.js/Tailwind/Prisma 技术栈构建并记录独立 SaaS 项目，仅将 FastAPI 用于 Python 工作负载，并遵循严格的架构规范。
- 用
ctx.state.safeParams存放清洗后的值，而非直接读ctx.query - 对常见动态字段（如
select、order、limit）提取公共校验函数 - 避免在
router.get()回调里写knex.raw()，优先走 QueryBuilder 链式 API
示例中间件：
const validateQuery = async (ctx, next) => {
const { fields = '*', order = 'id', dir = 'asc', limit = 20 } = ctx.query;
<p>// 白名单字段
const validFields = ['id', 'name', 'email', 'created_at'];
ctx.state.safeFields = fields === '<em>'
? '</em>'
: fields.split(',').filter(f => validFields.includes(f.trim()));</p><p>// 白名单排序字段 + 方向
ctx.state.safeOrder = validFields.includes(order) ? order : 'id';
ctx.state.safeDir = ['asc', 'desc'].includes(dir) ? dir : 'asc';</p><p>ctx.state.safeLimit = Math.min(Math.max(parseInt(limit, 10), 1), 100);</p><p>await next();
};调试时别用 toString() 检查注入风险
query.toString() 会把参数直接拼进 SQL（如 WHERE name = 'admin'），看起来“没问号”，容易误判为不安全；但它只是展示用途，真实执行仍走参数化。真正要验证是否安全，看 query.toSQL().bindings 是否包含原始用户输入：
- ✅ 安全：
bindings: ['O\'Reilly']—— 单引号被保留，说明没拼接 - ❌ 危险：
sql: "WHERE name = 'O'Reilly'"且无bindings—— 说明用了raw()或字符串模板
复杂点在于：Knex 不校验字段名、表名、排序方向这些“结构部分”，这部分必须由你用白名单兜底——它只保值，不保结构。
