sql注入风险源于字符串拼接而非orm本身；orm默认参数化查询安全，但raw()、extra()等方法会退化为拼接，需白名单校验字段名；输入应约束转换而非清洗；orm不防xss，前端渲染仍需转义。
SQL注入风险不来自ORM本身，而来自手拼字符串
用 ORM 并不自动防SQL注入——只要出现 + "WHERE id = " + user_input 或 f"SELECT * FROM users WHERE name = '{name}'" 这类操作，就等于把门打开。Django ORM、SQLAlchemy、TypeORM 等主流框架的查询接口（如 filter()、where()、find()）默认使用参数化查询，但前提是**你别绕过它们**。
- 常见错误现象：
ProgrammingError: syntax error at or near "admin"或更危险的静默执行（比如输入1 OR 1=1返回全部数据） - 真实使用场景：用户搜索关键词、分页传参、动态排序字段（此时需额外校验）、权限过滤中的组织ID拼接
- 关键区别：用
.filter(name__icontains=query)安全；用.extra(where=[f"name LIKE '%{query}%'"])危险
哪些ORM方法会悄悄退化成字符串拼接
不是所有“看起来像ORM”的写法都安全。有些API设计上就要求开发者自己兜底，或仅在特定模式下才启用参数化。
-
raw()（Django）、query()（Sequelize）、execute()（SQLAlchemy Core）：直接执行原始SQL，变量必须显式用占位符，如%s或:name，不能用 f-string 或+ -
extra()（Django）、addSelect()（TypeORM）：字段名/表名不支持参数化，若需动态，先白名单校验再拼接，例如if order_field in ["created_at", "score"]: qs.order_by(order_field) - 聚合函数中的字段引用：如
annotate(total=Sum("amount"))安全，但annotate(total=Sum(f"{user_col}"))不安全
用户输入进数据库前，该不该做“清洗”
不需要“清洗”，需要“约束”和“转换”。所谓清洗（如删空格、转小写、去HTML标签）是业务逻辑，不是安全措施；而类型转换、长度截断、枚举校验才是防止异常输入落地的关键。
- 字符串字段：用
max_length（Django）、length（TypeORM）、String(50)（SQLAlchemy）强制截断，避免超长输入撑爆索引或触发慢查询 - 数字字段：接收时用
int()或float()显式转换，捕获ValueError，不依赖ORM自动cast（某些驱动对空字符串行为不一致） - 布尔/状态字段：用枚举（
TextChoices、Enum），而非直接存字符串"true"/"false"，避免前端传"True"、"1"、"on"导致歧义
ORM查出的数据，前端渲染时仍可能XSS
ORM解决的是“怎么安全写入和读取数据库”，不是“怎么安全显示”。从DB读出来的内容，如果未经转义直接插入HTML，照样XSS。
- 典型错误：
return HttpResponse(f"<div>{user.bio}</div>")—— 即使bio是ORM查出的，也危险 - Django模板中
{{ bio }}默认转义，但{{ bio|safe }}会跳过，慎用 - FastAPI + Jinja2、Express + EJS 同理：渲染层要区分可信内容与用户输入，后者必须走
escape()或对应过滤器
事情说清了就结束。最常被忽略的点是：ORM只管到数据库边界，它不管HTTP请求头、URL路径段、Cookie值、前端JS拼接的API参数——这些地方一样要走参数化或白名单校验。
