SQL注入防护核心是参数化查询、权限最小化和输入白名单校验，而非多因素认证；ORM不自动防注入，DBA需关闭危险数据库配置。

SQL注入防护不能靠“强制多因素认证”解决

这里有个常见的误区：把多因素认证（MFA）当成数据库安全的万能钥匙。实际上，MFA保护的是用户登录环节，而SQL注入攻击发生在登录之后的数据操作环节。换句话说，即便在数据库连接层强制启用了MFA，对于像 SELECT * FROM users WHERE name = 'admin' OR '1'='1' 这样的注入攻击也完全无效。为什么？因为当这个恶意请求抵达时，用户身份认证早已完成，真正的攻击载荷就藏在SQL语句本身的结构里。

真正防SQL注入的三个落地动作

那么，有效的防线究竟在哪里？核心可以归结为三点：「参数化查询」、「权限最小化」和「输入不信任」。这可不是简单地增加几个认证开关就能实现的。

• 强制使用参数化查询接口：所有动态生成的查询语句，必须使用参数化接口来执行。在Ja va里是PreparedStatement，在PHP/PgSQL里是pg_query_params，在Python/psycopg2里则是cursor.execute(sql, params)。务必彻底告别用string.format或字符串拼接（+）来组装SQL的老习惯。
• 实施数据库账号业务隔离：根据“最小权限原则”来分配账号。例如，一个只负责查询用户列表的服务，其数据库账号就应该只拥有SELECT权限，并且最好将其访问范围限制在user_view这样的视图上，而不是直接开放users基表的访问权。
• 建立严格的后端输入白名单：对于前端传来的id、sort_by、limit等字段，后端必须进行白名单校验。比如，sort_by字段的值只能从['created_at', 'name']中选取，而limit值不仅要验证为整数，还必须设定一个上限（比如≤100）。

为什么ORM也不能自动防注入

另一个容易让人放松警惕的“安全幻觉”来自ORM（对象关系映射）。虽然主流的ORM框架默认封装了参数化查询的逻辑，但它们几乎都留有直接执行原生SQL的“后门”。一旦开发人员使用了这些接口，防护就瞬间失效了。

• 像Django的raw()方法、SQLAlchemy的text()函数，或者MyBatis中动态拼接SQL的${}语法（注意，这与安全的#{}占位符不同），都会绕过参数化保护。
• 举个例子：queryset.filter(name__icontains=request.GET.get('q')) 是安全的，因为它使用了ORM的安全方法。
• 但 Model.objects.raw("SELECT * FROM app_user WHERE name LIKE '%" + q + "%'") 就危险了，它直接拼接了用户输入。
• 即便是使用参数化接口，也需注意细节：session.execute(text("UPDATE logs SET status = :s WHERE id = :id"), {"s": status, "id": id}) 是安全的；但如果错误地构造了参数，如 {"s": f"'{status}'"}，就等于又把字符串拼回去了，前功尽弃。

DBA侧最容易被忽略的加固点

即使应用层做得滴水不漏，如果数据库自身的配置存在疏漏，那也如同锁好了大门却留着一扇敞开的窗户。数据库管理员（DBA）有几个关键的配置点需要特别注意：

• 审慎启用统计插件：除了必要的pg_stat_statements，应禁用其他可能泄露SQL结构的统计插件。例如，如果开启了auto_explain并设置log_min_duration_statement=0，完整的SQL语句可能会被记录到日志中，存在泄露风险。
• 控制活动追踪：在PostgreSQL中，除非确实需要用于监控，否则应考虑关闭track_activities和track_counts。这可以防止pg_stat_activity等系统视图暴露未脱敏的实时查询文本。
• 严格SQL模式：对于MySQL 8.0及以上版本，必须设置sql_mode包含STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION。否则，像'1 OR 1=1'这样的注入输入可能会被静默截断为'1'后执行，从而绕过一些简单的防御。

说到底，防范SQL注入从来不是靠增加一层认证就能交差的任务。它是一项需要开发、运维、DBA多方协同的“细节活”，要求每一个SQL调用点、每一个数据库账号、每一项相关配置都对齐安全标准。历史经验表明，最常出问题的地方，恰恰是“以为ORM已经兜底了”和“DBA觉得这该应用层管”的中间地带。只有两端都压实责任，才能真正堵住漏洞。