全局防御SQL注入需在各层设防：必须全程使用参数化查询，落实最小权限数据库账号，禁用所有动态SQL拼接路径，并通过WAF、AST扫描、白名单校验等多手段协同防护。
全局防御 SQL 注入，不是靠某一层加个过滤器就能解决的——它必须在数据流转的每个关键节点设防，且各层防御不能互相抵消或绕过。核心是：参数化查询必须贯穿所有数据库访问点，最小权限账号必须落实到每个服务实例，而任何动态拼接 SQL 的路径（比如日志归档、分库分表路由、审计写入）都得被显式识别并禁用。
所有数据库客户端必须强制使用参数化查询
只要存在 execute 或 query 方法接受原始字符串 + 参数数组/对象的组合，就极易被绕过。比如 Node.js 的 pg 库支持 client.query('SELECT * FROM users WHERE id = $1', [id])，但若有人误用 client.query(`SELECT * FROM users WHERE id = ${id}`)，就直接破防。
- Java 侧检查所有
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”这件事在代码库里变成一件显眼、难隐藏、易被扫描到的异类行为。
