全局防御 SQL 注入，靠某一层加个过滤器根本不够——它必须在数据流转的每个关键节点设防，而且各层防御之间不能互相抵消或留下绕过的缝隙。核心思路其实很清晰：参数化查询必须贯穿所有数据库访问点，最小权限账号必须落实到每个服务实例，任何动态拼接 SQL 的路径——比如日志归档、分库分表路由、审计写入——都得被显式识别并彻底禁用。这才是全局防御的基调。
所有数据库客户端必须强制使用参数化查询
只要项目中存在execute或query方法可以接受原始字符串+参数数组/对象的组合，就存在被绕过的风险。举个例子，Node.js 的 pg 库虽然支持 client.query('SELECT * FROM users WHERE id = $1', [id]) 这种安全写法，但一旦有人误用 client.query(`SELECT * FROM users WHERE id = ${id}`)，防线瞬间就破了。
- 在 Ja va 项目中，要检查所有
Statement.execute()、Statement.executeQuery()调用，禁止传入拼接字符串；只允许使用PreparedStatement+setXxx()。 - 对于 Python 项目，禁用
cursor.execute("SELECT ... %s" % value)和f"SELECT ... {value}"这类写法，CI 流水线中应加入 AST 扫描规则，比如 semgrep 的python.lang.security.sql-injection。 - 在 Go 的
database/sql中，db.Query(fmt.Sprintf(...))属于高危模式，必须替换为db.Query("SELECT ... WHERE id = ?", id)。 - MyBatis 用户尤其要注意：
${}本质是字符串替换，等同于拼接，哪怕只用于表名也极其危险；#{}才是预编译，但无法用于列名或表名——这类动态结构应走白名单校验，而非直接放行。
每个微服务连接数据库时必须使用独立最小权限账号
一个服务连接数据库用 app_order_reader，另一个用 app_user_writer，这不仅仅是为了管理方便，更关键的是：一旦某个服务被注入，攻击者最多只能读取订单表或修改用户表，无法跨域操作，这叫纵深防御。
- 在 MySQL 中，为每个服务单独创建账号，只授予
GRANT SELECT ON order_db.orders TO 'app_order_reader'，不授权information_schema写权限，也不给USAGE以外的全局权限。 - PostgreSQL 中应避免使用
publicschema 授权，明确GRANT SELECT ON TABLE orders TO app_order_reader，并确保该角色不在pg_catalog上拥有SELECT权限，除非确实需要查询系统表。 - 在 Kubernetes 环境下，账号密码通过 Secret 注入，禁止硬编码或存入 ConfigMap；ServiceAccount 绑定的 RBAC 不应包含对数据库凭证资源的读权限。
- 验证方式很简单：登录该账号后执行
DROP TABLE IF EXISTS fake;，必须返回permission denied；执行SELECT * FROM pg_tables WHERE schemaname = 'pg_catalog';应报错或返回空结果。
中间件与网关层需识别并拦截 DDL 类关键词（仅作兜底）
WAF 或 API 网关拦截 CREATE、DROP、ALTER 并不是为了替代权限控制，而是防住那些漏掉的、非业务路径上的漏洞——比如调试接口、旧版管理后台、未下线的测试路由。这一层是兜底，不是主防线。
- 腾讯云 WAF、Cloudflare Rules 或 OpenResty + lua-resty-waf 都可以配置正则规则，匹配
\b(DROP|CREATE|ALTER|TRUNCATE|EXEC|xp_cmdshell)\b，注意大小写和空格边界。 - 不要依赖简单的关键字黑名单：攻击者可以用
%20DROP%0aTABLE、/**/DROP/**/TABLE或十六进制编码轻松绕过。应启用语义解析引擎，比如 WAF 的 AI 模式。 - 重点监控响应体中包含
mysql_fetch_array、psycopg2.ProgrammingError、ORA-00900等错误信息的请求——这类暴露式错误本身就会助推盲注攻击。 - 日志中间出现连续多个包含
UNION SELECT、SLEEP(5)、AND 1=1的请求，应自动触发 IP 封禁，而非仅仅告警了事。
ORM 和分库分表组件容易成为隐性缺口
很多团队以为用了 MyBatis 或 Hibernate 就万事大吉，但分库分表中间件——比如 ShardingSphere、Vitess——或者自研的路由逻辑，常常在 SQL 解析、重写、下发阶段重新拼接语句。这里一旦出问题，前面所有的参数化防护都白费。
- ShardingSphere 的
sql.parser.cache默认开启，但若配置了sql.show=true且日志输出原始 SQL，可能意外泄露拼接痕迹。生产环境必须关闭这个选项。 - Vitess 的 VSchema 如果定义了动态表名映射，后端生成 SQL 时若使用
fmt.Sprintf("SELECT * FROM %s", tableName)，就等于为攻击者留了后门。 - 自研分表路由务必校验表名是否在白名单内，比如只允许
orders_202406、orders_202407这类格式，禁止接受orders; DROP TABLE users--这样的输入。 - 所有 SQL 构建逻辑必须经过统一的
SQLSanitizer工具链校验，这个工具应能识别占位符是否被真实绑定，而非仅仅检查字符串里有没有?。
真正难防的，从来不是 ' OR 1=1 -- 这种经典攻击，而是某个运维脚本、某个离线导出任务、某个灰度环境的 debug 接口，悄悄绕过了主流程的参数化约束。全局防御的关键，是让"拼接 SQL"这件事在代码库里变得显眼、难以隐藏、容易被扫描到——这才是真正的防御之道。
