SQL注入因用户输入直接拼入WHERE等执行上下文而触发；须用参数化查询（如sqlite3的?、psycopg2的%s或%(name)s），禁用字符串拼接；动态结构（表名、列名等）需白名单校验。
SQL注入是怎么被触发的
不是所有拼接字符串的查询都会出事，但只要用户输入直接进了WHERE或ORDER BY这类执行上下文，风险就坐实了。典型错误是把前端传来的user_id直接拼进SQL里："SELECT * FROM users WHERE id = " + request.query.id——这时候攻击者传个1 OR 1=1 --，整张表就裸奔了。
- 危险操作：用
+、format()、%等拼接用户数据到SQL字符串中 - 高危位置：
WHERE、ORDER BY、GROUP BY、LIMIT（后两者尤其容易被忽略） - 注意：即使做了
parseInt()或正则过滤，也不能替代参数化——绕过方式太多，比如十六进制编码、Unicode变体
Python里用sqlite3和psycopg2怎么写安全查询
核心就一条：让驱动自己处理值的转义和类型绑定，别碰字符串拼接。不同库占位符语法不同，混用会报错，而且execute()第二个参数必须是元组或字典，不能是单个值。
-
sqlite3只认?位置占位符：cursor.execute("SELECT * FROM logs WHERE level = ?", ("ERROR",))（注意("ERROR",)末尾逗号不能少） -
psycopg2支持%s（位置）和%(name)s（命名），但%s不是Python字符串格式化，是驱动专用标记：cur.execute("SELECT * FROM users WHERE status = %(s)s", {"s": "active"}) - 绝对不要用
f-string或.format()插变量，哪怕你“确认过是数字”——类型校验在数据库层之前就该由参数化兜底
JavaScript里pg和mysql2的参数化陷阱
Node.js生态里最常踩的坑是误以为query("SELECT * FROM t WHERE id = " + id)加了escape()就安全——其实mysql2.escape()只是转义单引号，防不住id=1; DROP TABLE users;这种堆叠注入。
-
pg必须用数组或对象传参：client.query("SELECT * FROM posts WHERE slug = $1", [slug])，$1不能写成"$" + 1 -
mysql2用?占位，但IN子句无法直接参数化（WHERE id IN (?)只会当一个值）——得动态生成?, ?, ?再展开数组 - ORM如Prisma、TypeORM默认启用参数化，但手写
raw()或unsafe()方法时，等于主动拆掉防护罩
哪些地方参数化也救不了，得换思路
参数化只管“值”，不管“结构”。一旦用户输入要决定字段名、表名、排序方向或分页偏移量，就得用白名单硬控，或者彻底拒绝动态拼结构。
- 动态列名（如
ORDER BY ${field}）：只允许["created_at", "score", "name"]里的值，其他一律拒掉 - 动态表名（如多租户
SELECT * FROM tenant_${id}.logs）：查配置表确认租户ID对应真实schema名，再拼接，不信任任何输入 -
LIMIT和OFFSET：用parseInt()转整数后加范围限制（如Math.min(offset, 10000)），避免超大偏移拖垮查询
真正难的不是写对那行execute()，而是想清楚哪部分输入能进参数、哪部分连参数化都接不住——后者往往藏在业务逻辑最顺手的动态拼接里。
