即使有ORM底层配置不当仍会导致SQL注入

ORM框架确实无法从根源上杜绝SQL注入，这可能是不少开发者的认知盲区。问题的关键不在于ORM本身，而在于那些绕过参数化机制的原生接口——比如raw()、text()这类方法，以及表名、字段名、排序字段等结构化内容无法通过参数化来处理。事实上，只要涉及这些“结构部分”的用户输入，就必须依赖白名单校验来兜底。

ORM的防护能力是有前提的：只有当你“用对方式”时，它才起作用。一旦配置或写法偏离了安全路径——比如启用了原生SQL、关闭了参数绑定、或者在结构层面做动态拼接——那这层防护就等于没有。今天我们就来逐一拆解主流ORM框架中那些容易踩的坑。

SQLAlchemy 中 text() 不带命名参数直接执行原生 SQL

很多人有个错觉：用了text()就算走了ORM的安全通道。其实不然——如果只是把字符串一股脑塞进去，不用{"param": value}的方式传参，数据库收到的依然是完整拼接后的语句，参数化防护完全没起作用。

• 常见误用：session.execute("SELECT * FROM users WHERE name = '" + name + "'") —— 无论是f-string还是加号拼接，本质上都是裸SQL注入的入口。
• 修复代码：session.execute(text("SELECT * FROM users WHERE name = :name"), {"name": name})
• 额外提醒：:name这个命名占位符必须和字典的键名严格一致；?占位符在SQLAlchemy的text()里是不被识别的，用了会报错。

Django raw() 和 extra() 跳过 ORM 编译器

这两个方法本质上就是绕过Django的参数化机制，直接生成SQL字符串。哪怕只是在字段名或条件值这里拼了一丁点用户输入，解析权就已经交回给数据库引擎了。

• 错误示范：MyModel.objects.raw(f"SELECT * FROM myapp_mymodel WHERE status = '{status}'")
• 正确写法：MyModel.objects.raw("SELECT * FROM myapp_mymodel WHERE status = %s", params=[status])
• 特别注意：extra()的where参数同样危险——.extra(where=["name = '" + user_input + "'"]) 必须改用params传参，而且只支持位置参数。

MyBatis 使用 ${} 替换而非 #{}

这个区别在XML映射文件里尤其容易忽略。${}是字符串替换，不参与参数化；#{}才会触发PreparedStatement绑定。很多开发者只是想实现“动态表名”或“动态排序字段”，结果手一滑选错了。

• 高危写法：SELECT * FROM ${tableName} WHERE id = ${id} —— 表名和值全被拼接到一起，等于门户大开。
• 安全做法：SELECT * FROM user WHERE id = #{id}（值部分安全了），但表名部分必须硬编码或者走白名单校验。
• 排序字段同理：ORDER BY ${sortField}无法参数化，必须限制为if sortField not in ["created_at", "name"] 这样的白名单判断。

Hibernate HQL / Criteria 中混入用户控制的属性名

HQL本身是支持参数化的，但属性路径（比如user.name）如果来自用户输入，就会绕过所有防护。Hibernate不会对属性名做任何转义，它直接编译成SQL字段引用。

• 危险操作：String hql = "FROM User u WHERE u." + fieldName + " = :value" —— 攻击者传一个fieldName=class.classloader.resources.context，触发的可能就不只是SQL注入了，还可能牵连反射链。
• 安全方案：字段名必须来自预定义的映射表，比如Map.of("username", "u.username", "email", "u.email")，然后再查表取值。
• Criteria API相对更安全，但也取决于你是否避开Root.get(requestedField)这种动态获取方式。

说来说去，最常被忽略的一点是：ORM的防护只覆盖“值”，不覆盖“结构”。表名、列名、函数名、ORDER BY、GROUP BY，甚至HQL里的类名——只要这些由用户输入决定，又没有经过白名单或静态映射的预处理，参数化机制就完全派不上用场。