网关层校验对SQL注入基本无效，因其仅处理HTTP参数而无法感知SQL构建逻辑，且“过滤单引号”等规则易被URL编码、大小写混用等绕过，还会误杀合法输入；真正有效防护必须在数据库访问层实施参数化查询。
网关层做参数校验不能阻止SQL注入，它只能作为辅助手段；真正有效的修复必须落在数据库访问层，用参数化查询。
为什么网关层校验对SQL注入基本无效
网关（如 Nginx、Kong、Spring Cloud Gateway）看到的只是原始 HTTP 请求参数，比如 user_id=123 或 keyword=admin' OR '1'='1。它无法知道这些值后续会在哪条 SQL 里怎么拼接 —— 也就是说，网关不参与 SQL 构建过程，也看不到最终执行的语句。所谓“过滤单引号”“拦截 OR 1=1”这类规则，既容易被绕过（如用 URL 编码、大小写混用、注释符 --、内联注释 /* */），又会误杀合法输入（比如用户真名叫 O'Connor）。
常见错误现象：
- 加了网关正则拦截
'后，用户搜索“iPhone 13’”失败 - 用
%27（'的 URL 编码）绕过网关检测，后端仍拼接进 SQL 导致漏洞复现 - 网关规则越写越多，维护成本高，但漏洞依然存在
网关能做的合理边界：类型/长度/格式初筛
网关适合做轻量、无状态、与业务逻辑解耦的前置过滤，目标是减少后端无效请求压力，不是防注入。
可操作建议：
- 对
user_id这类明显应为数字的字段，用正则^[0-9]+$拒绝非数字请求（注意：仅限纯数字 ID，不适用于带前缀的编号如U123） - 限制
keyword最大长度（如 ≤ 200 字符），防止超长 payload 触发后端解析异常或缓冲区问题 - 拒绝明显畸形编码，如连续多个
%、未闭合的 URL 编码（%2）、含空字节%00 - 不尝试识别 SQL 关键字（
SELECT、UNION等）—— 它们可能合法出现在日志、配置、富文本中
真正起作用的修复点：必须落到后端数据访问层
SQL 注入的本质是“代码与数据未分离”。唯一可靠方案，是在执行 SQL 前，由数据库驱动或 ORM 显式区分结构和参数。
实操要点：
- 禁止任何形式的字符串拼接构造 SQL，包括
"SELECT * FROM users WHERE id = " + userId、f"WHERE name = '{name}'"、fmt.Sprintf("WHERE status = %s", status) - Java 用
PreparedStatement，占位符统一用?，调用setString()/setLong()设置值 - Python 用
cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])（PostgreSQL/MySQLdb）或sqlite3的?占位符，绝不用.format()或%插入 - Node.js 用
pg.query("SELECT * FROM users WHERE id = $1", [id])（pg），或mysql2的query("SELECT * FROM u WHERE name = ?", [name]) - ORM 如 MyBatis 必须用
#{}（预编译），禁用${}（字符串替换）；Django ORM 默认安全，但手动写extra()或raw()时需格外警惕
容易被忽略的“伪安全”场景
有些做法看似加固，实则无效甚至误导：
-
mysql_real_escape_string()（PHP）或类似转义函数：只对特定连接字符集有效，且无法防御数字型注入（如id=1 OR 1=1中无引号） - 前端 JS 校验：完全可绕过，攻击者直接发 curl 就跳过
- 把所有参数先 base64 编码再传给后端：后端 decode 后照样拼 SQL，等于没防
- 只在登录接口修了，其他接口（如搜索、导出、详情页）仍用拼接：一个漏洞就全盘失守
最麻烦的地方在于：SQL 注入往往藏在老代码、动态查询构建、或第三方 SDK 封装的底层调用里。别信“这个接口很简单，不可能有注入”，重点审计所有带用户输入参与 SQL 拼接的路径，尤其是 ORDER BY、GROUP BY、表名/字段名动态拼接这类高危位置。
