如何修复TypeORM动态SQL注入风险

动态字段名拼接必须白名单校验，且参数绑定须用计算属性语法；JSONB模糊查询需确保字段为JSONB类型并建GIN索引；复杂场景应改用原生SQL+占位符参数化。

动态字段名拼接必须白名单校验

TypeORM的andWhere对于字段名（比如JSONB路径row_data->>'Location'里的Location）无法进行参数化处理。要是直接用${key}拼接，那可是会引发SQL注入问题的。像攻击者就可能传入类似Location'; DROP TABLE users; --这样的恶意载荷。

正确做法是预先定义允许过滤的字段列表，并严格校验：

• const allowedKeys = ['Location', 'Status', 'Department', 'CreatedAt'];
• 循环中先判断：if (!allowedKeys.includes(key)) continue;
• 绝不依赖客户端传来的任意字符串作为字段名或表名

命名参数绑定必须用计算属性语法

动态生成参数名时，若写成 { paramName: value }，TypeORM 会查找字面量键 "paramName"，而非你期望的 "searchVal1"，导致参数未绑定、查询失败甚至暴露原始错误。

必须使用方括号语法确保键名动态解析：

• ✅ 正确：query.andWhere(`myTable.row_data->>'${key}' ILIKE :${paramName}`, { [paramName]: `%${value}%` });
• ❌ 错误：{ paramName: `%${value}%` } —— 这等价于 { "paramName": "xxx" }，TypeORM 找不到 :searchVal1
• 参数名建议带前缀（如 searchVal1），避免和固定参数（如 :id）冲突

JSONB 模糊查询需确认数据库配置

row_data->>'Location' 是 PostgreSQL 特有语法，提取 JSONB 字段值为 text 后做 ILIKE。这要求：

• 目标列类型确实是 JSONB（不是 JSON 或 TEXT）
• 已创建 GIN 索引：CREATE INDEX idx_row_data_gin ON myTable USING GIN (row_data);
• 若字段可能为 NULL 或路径不存在，->> 返回 NULL，ILIKE 会跳过该行 —— 这是预期行为，无需额外 IS NOT NULL

更安全的替代方案：改用原生查询 + 参数化

当过滤逻辑复杂、字段多变且无法预设白名单时，硬编码白名单会失去灵活性。此时应放弃 QueryBuilder，改用 queryRunner.query() 配合完全参数化的原生 SQL：

• 字段名仍需白名单校验（不可绕过）
• 值部分全部用 $1, $2 占位符，由驱动层绑定，彻底隔离数据与结构
• 示例：await queryRunner.query(`SELECT * FROM myTable WHERE row_data->>$1 ILIKE $2`, [key, `%${value}%`]);
• 注意：queryRunner 需手动获取，且事务上下文需自行管理

白名单校验和计算属性参数绑定这两步漏掉任何一项，都可能让防护形同虚设。字段名不校验，参数再安全也挡不住注入；参数名写错，查询直接报错，还可能把内部结构暴露给攻击者。