启用防火墙时GET请求含数字+delete/truncate关键词报403，求GET兼容方案

我之前也碰到过类似的Web应用防火墙（WAF）拦截问题，这种情况大概率是防火墙的SQL注入防护规则在起作用——它把「数字+delete/truncate」的组合判定为潜在的注入攻击行为，所以直接返回了403。给你几个不用修改防火墙规则、同时能保留GET请求的可行方案：

• Base64编码参数内容
  前端把要搜索的字符串转成Base64编码后再通过GET参数传递，后端接收后解码还原成原内容。比如搜索「122 delete」，前端转成Base64字符串 MTIyIGRlbGV0ZQ==，然后请求接口时传 ?search=MTIyIGRlbGV0ZQ==，后端解码后拿到原搜索内容再处理。这种方法能让防火墙看不到敏感关键词，因为传递的是编码后的无意义字符串。
  注意：Base64是编码不是加密，后端要做好解码失败的异常处理，避免出现逻辑错误。

• 拆分搜索参数
  把包含数字和敏感词的搜索内容拆成两个独立参数传递，比如一个参数存数字部分，另一个存文本部分。比如搜索「122 delete」时，请求接口传 ?num=122&content=delete，后端在业务逻辑里把两个参数拼接成「122 delete」再执行搜索。因为敏感词和数字不在同一个参数里，防火墙的规则就不会被触发。

• 自定义字符替换+后端还原
  前端对敏感词做简单的字符替换，比如把「delete」改成「de_x_lete」，后端收到参数后再把「x」替换回「l」；或者用Unicode转义字符替换部分字母（比如把「d」转成 \u0064）。只要替换后的内容不会触发防火墙规则，同时后端能正确还原成原内容就可以。

• 更换参数名
  有些WAF会针对常见的搜索参数名（比如search、query）做重点检测，你可以尝试把参数名改成更冷门的，比如qry、s_key，说不定能避开规则的检测。不过这个方法依赖防火墙的具体配置，不一定100%有效，但成本很低，可以先试试。

另外补充一下：你提到HTML编码无效，是因为现在大部分WAF会自动解码URL编码后的内容再进行规则检测，所以单纯的%20替换根本躲不过检测。上面的方案都是通过改变参数的呈现形式，让防火墙无法识别出敏感组合，同时保证后端能正常处理原搜索内容。

内容的提问来源于stack exchange，提问作者Matt