很多开发者对ORM有一种天然的信任感，认为用了框架自带的查询构造器就万事大吉，SQL注入从此与自己无关。这种想法在大多数常规场景下是成立的，因为ORM的核心价值之一就是通过参数绑定来自动转义输入值。然而，当业务复杂度上升，我们需要绕过ORM的抽象层直接执行原生SQL时，安全防线就会出现裂缝。问题不在于ORM本身，而在于开发者在使用原生查询功能时，习惯性地将外部输入直接拼接到SQL字符串中，亲手关闭了框架提供的保护机制。

原生查询的诱惑与陷阱

几乎市面上所有主流的ORM框架，无论是Python生态的Django ORM、SQLAlchemy，PHP的Eloquent，还是Node.js的TypeORM，都提供了执行原始SQL的接口。这些接口设计的初衷是为了解决ORM抽象层无法高效处理的复杂查询，比如涉及窗口函数、递归查询、特定数据库方言的高级特性，或者对性能有极致要求的批处理操作。问题就出在这里：框架在设计这些原生接口时，为了保持灵活性，通常提供了两种传参方式。一种是带参数绑定的安全方式，另一种是直接接收完整SQL字符串的快捷方式。而开发者往往因为图方便或者对安全机制理解不深，选择了后者。

拼接字符串是如何毁掉安全性的

让我们看一个具体的例子。假设我们使用Python的Django框架，需要根据用户输入的用户名来查询用户信息。错误的写法是这样的：

from django.db import connection

def get_user_by_name_unsafe(username):
    with connection.cursor() as cursor:
        # 危险！直接拼接用户输入
        query = f"SELECT * FROM users WHERE username = '{username}'"
        cursor.execute(query)
        return cursor.fetchone()

在这段代码里，username变量直接通过f-string嵌入到SQL语句中。如果攻击者输入的username是 ' OR '1'='1，那么最终执行的SQL就会变成 SELECT * FROM users WHERE username = '' OR '1'='1'，这将返回users表中的所有记录。更可怕的是，如果攻击者输入 '; DROP TABLE users; --，整个表都可能被删除。这就是典型的SQL注入攻击，而罪魁祸首就是字符串拼接。

参数绑定：你本应使用的正确方式

同样是Django的原生查询，安全的写法应该是利用参数绑定，将用户输入作为参数传递给执行函数，而不是直接拼进SQL字符串。正确的代码如下：

from django.db import connection

def get_user_by_name_safe(username):
    with connection.cursor() as cursor:
        # 安全：使用参数占位符
        query = "SELECT * FROM users WHERE username = %s"
        cursor.execute(query, [username])
        return cursor.fetchone()

在这个修正版本中，%s 是一个占位符，实际的username值通过列表 [username] 传递给execute方法。数据库驱动会在执行前对参数进行正确的转义和处理，确保它被当作一个纯粹的数据值，而永远不会被解释为SQL代码的一部分。无论攻击者输入什么内容，都只会被当作一个普通的字符串去匹配username字段，注入攻击完全失效。这个原则适用于所有ORM框架，只是占位符的语法略有不同。SQLAlchemy使用 :name 形式的命名参数，Eloquent使用 ? 占位符或命名绑定，TypeORM则使用 $1, $2 这样的索引占位符。

那些容易被忽略的复杂场景

参数绑定能解决绝大多数问题，但有一些场景会让开发者感到棘手，从而再次掉入拼接陷阱。最典型的就是动态表名、列名或者SQL关键字。参数绑定机制的设计前提是，占位符只能替代数据值，比如字符串、数字、日期等，而不能替代SQL语句的结构部分。如果你试图用占位符来绑定一个表名，数据库会报错，因为它会把表名当作一个字符串字面量来处理，而不是一个数据库对象标识符。

例如，下面这种写法是行不通的：

# 错误示范：试图用参数绑定表名
table_name = request.GET.get('table')
cursor.execute("SELECT * FROM %s WHERE id = %s", [table_name, user_id])

数据库会认为你要从一个名为 'my_table'（带着引号）的字符串字面量里查询数据，这显然会失败。面对这种需求，最安全、最负责任的做法是建立一个白名单映射。绝不将用户输入直接作为表名或列名，而是让用户输入一个标识符，然后在服务端将这个标识符映射到预定义的、受信任的表名或列名上。

# 安全做法：白名单映射
TABLE_MAP = {
    'users': 'auth_user',
    'orders': 'sales_order',
    'products': 'product_catalog'
}

def get_data_by_table(table_key, item_id):
    if table_key not in TABLE_MAP:
        raise ValueError("Invalid table key")
    real_table = TABLE_MAP[table_key]
    # 现在real_table是受信任的，可以安全地格式化进SQL
    query = f"SELECT * FROM {real_table} WHERE id = %s"
    cursor.execute(query, [item_id])

如果业务场景极其复杂，无法预先定义白名单，那么必须对动态标识符进行极其严格的清洗和转义。这需要根据具体使用的数据库系统，调用其官方提供的标识符引用函数。例如，在PostgreSQL中，可以使用 psycopg2.sql 模块提供的 Identifier 和 SQL 工具来安全地处理动态SQL结构。手动编写正则表达式来过滤是最后的手段，而且非常容易出错，强烈不推荐。

ORM查询构造器中的“特洛伊木马”

很多人以为只要使用了ORM的查询构造器方法，而不是写原生SQL，就绝对安全。这是一个危险的误解。ORM的查询构造器在绝大多数情况下确实会进行参数绑定，但某些方法如果使用不当，同样会引入注入漏洞。最臭名昭著的例子就是Django ORM中的 extra() 方法和 RawSQL 表达式，以及SQLAlchemy中的 text() 构造与 + 运算符拼接。

看看这段Django代码：

# 危险的extra()用法
user_input = request.GET.get('username')
users = User.objects.extra(
    where=[f"username = '{user_input}'"]
)

extra() 方法中的 where 参数接受一个字符串列表，这些字符串会被直接插入到生成的SQL的WHERE子句中。如果 user_input 没有被恰当地处理，这里就产生了一个SQL注入点。正确的做法是使用 extra() 的 params 参数来传递值：

# 安全的extra()用法
user_input = request.GET.get('username')
users = User.objects.extra(
    where=["username = %s"],
    params=[user_input]
)

同样，在SQLAlchemy中，使用 text() 构造查询时，如果不使用绑定参数，也会面临风险。务必使用 :param 形式的命名参数，并在执行时传递一个参数字典。始终牢记一个原则：在ORM的世界里，任何允许你传入原始SQL字符串片段的功能，都是一个潜在的风险点。在使用这些功能之前，必须查阅官方文档，确认其安全的参数传递方式。

存储过程和动态SQL的双重风险

有些系统为了性能或封装业务逻辑，会使用数据库存储过程。调用存储过程本身通常可以通过ORM的参数绑定安全地进行。然而，真正的风险潜伏在存储过程的内部实现。如果一个存储过程内部使用了动态SQL，并且拼接了从外部传入的参数，那么即使你的应用代码是安全的，攻击者依然可以通过你调用的存储过程发动二次注入攻击。这是一个非常隐蔽的盲区。

作为开发者，如果你负责维护的存储过程需要构建动态SQL，必须在数据库层面就使用其提供的参数化执行能力。例如，在Microsoft SQL Server中，应使用 sp_executesql 来执行动态构建的SQL语句，并将外部参数作为参数传递给它，而不是直接拼字符串后EXEC。在MySQL中，应使用PREPARE语句。在PostgreSQL中，应使用 EXECUTE ... USING 语句。安全责任需要贯穿从应用层到数据库层的整个调用链。

代码审查中的关键检查点

理解了上述风险点后，我们可以在代码审查中建立一套高效的检查机制，专门用于捕捉原生查询相关的SQL注入漏洞。这套机制不需要复杂的工具，只需要审查者带着几个明确的问题去审视每一段代码。首先，搜索所有使用了原生SQL执行函数的地方，比如 execute(), raw(), query(), send() 等。其次，检查这些函数的SQL字符串参数是如何构建的。如果看到任何形式的字符串拼接、格式化操作（如f-string, .format(), + 运算符）涉及外部变量，立即标记为高危。最后，即使看到了参数绑定，也要追问：这里绑定的都是数据值吗？有没有动态表名、列名？如果有，它们是否来自白名单？对于存储过程调用，要追问其内部实现是否安全。

将这些问题固化为代码审查清单，可以系统性地降低人为失误导致的安全漏洞。同时，配合使用静态代码分析工具，如Bandit（Python）、Brakeman（Ruby）、SonarQube等，可以自动扫描出常见的SQL注入模式，作为人工审查的有力补充。

构建纵深防御体系

安全不应该依赖单一环节。即使开发者足够谨慎，也不能保证万无一失。因此，在架构层面建立纵深防御至关重要。最小权限原则是最有效的一层防护。应用程序连接数据库所使用的账号，其权限应该被严格限制到仅能满足业务需求。如果一个业务模块只需要对 users 表进行SELECT和INSERT操作，那么这个账号就不应该拥有对该表的DROP或DELETE权限，更不用说对整个数据库的DDL权限了。这样，即使某个SQL注入漏洞被成功利用，攻击者能造成的破坏也会被限制在最小范围内。

数据库防火墙或Web应用防火墙是另一道防线。它们可以通过分析流量中的SQL语句模式，识别并拦截恶意的注入尝试。虽然这不是绝对可靠的，但能有效提高攻击成本。最后，确保错误信息不会泄露数据库结构。生产环境必须关闭详细的错误回显，使用自定义的、通用的错误页面。攻击者常常利用数据库报错信息来推断表名、列名，从而发动更精准的注入攻击。

ORM原生查询是一把双刃剑，它赋予了开发者突破抽象层限制的能力，但也将保护数据安全的责任更多地转移到了开发者手中。没有绝对安全的框架，只有时刻保持警惕的工程师。将“永远不要信任外部输入”这条铁律刻在每一次编码的思考中，配合参数绑定、白名单验证和纵深防御，才能真正做到既享受原生查询的灵活性，又守住数据安全的底线。