速读摘要：放行规则写不好等于开后门。按风险从高到低，放行方式依次是 IP 白名单 > URI 放行 > 字段免检 > 条件组合。核心原则是"能细不粗、能限不限、能不就不"——优先用字段级免检和条件组合，尽量避免大范围 IP 白名单和全局关闭规则。本文给出多种场景的精确写法。
一、放行是最容易出事的地方
拦截规则写错了顶多是误报，放行规则写错了就是安全漏洞。因为放行意味着”跳过检测”，一旦范围过大，攻击者就能从这个口子长驱直入。
二、放行方式的粒度排序
| 方式 | 粒度 | 风险 | 说明 |
|---|---|---|---|
| 条件组合放行 | 最细 | ★★★★★ 最低 | URI+字段+IP 多重限制 |
| 字段免检 | 细 | ★★★★ | 只对某参数的某类检测放行 |
| URI 放行 | 中 | ★★★ | 某路径不做某类检测 |
| IP 白名单 | 粗 | ★★ | 该 IP 绕过所有检测 |
| 关闭规则 | 最粗 | ★ 最高 | 全局禁用某条规则 |
越往上越安全，越往下越危险。写放行规则时，优先选上层的方案。
三、五个场景的精确写法
场景 1：富文本编辑器提交被拦
❌ 糟糕写法：
/admin/article/edit 整个路径关闭 XSS 检测
→ 攻击者也可以利用这个路径传 XSS
✅ 精确写法：
仅对参数 content 关闭 XSS 字符检测
但仍保留：
├─ 文件上传检测
├─ 频率限制
└─ 提交后服务端二次过滤（白名单标签）场景 2：搜索框输入单引号被拦
❌ 糟糕写法：
/search 路径完全关闭 SQL 注入检测
✅ 精确写法：
匹配：URI = /search AND 参数名 = q
动作：该参数仅做"关键字黑名单"检测
同时保留：
├─ q 参数长度限制（≤ 100 字符）
├─ 频率限制（5 次/秒）
└─ 后端仍使用参数化查询场景 3：APP 接口请求被拦
❌ 糟糕写法：
/api/* 所有路径关闭全部检测
✅ 精确写法：
匹配：URI 前缀 /api/
条件：请求头包含 X-App-Sign（签名校验）
动作：跳过 UA / Bot 检测，保留：
├─ SQL 注入 / XSS 检测
├─ 频率限制
└─ 签名有效性校验场景 4：上传合法业务文件被拦
❌ 糟糕写法：
全站关闭文件上传检测
✅ 精确写法：
匹配：URI = /upload/document
条件：文件类型为 .doc/.xls/.pdf（校验文件头）
动作：放行
同时：
├─ 其他路径的上传检测照常
├─ 限制单文件 ≤ 20MB
└─ 上传目录禁止执行脚本（核心！）场景 5：监控探针被频率限制
❌ 糟糕写法：
把探针所在的大网段加入 IP 白名单
✅ 精确写法：
匹配：User-Agent = "HealthCheck/1.0"
条件：源 IP = 探针固定 IP
动作：豁免频率限制
→ 只放行"特定 UA + 特定 IP"的组合，
其它情况正常检测四、放行的额外保险
即使做了精确放行，也建议加几层保险：
- 后端二次校验：放行不等于信任，服务端仍要过滤（参数化查询、输出转义）
- 限制放行范围：只放行必要的检测项，其他照旧
- 加时间限制：临时放行可以设有效期，到期自动恢复
- 记录日志：放行的请求也要记录，便于事后追溯
- 定期复核：每月检查放行规则，清理不再需要的
五、一个重要的原则
很多误报其实可以通过调整阈值、改用语义分析、增加白名单字段来精准解决，根本不需要放行。放行应该是最后手段，而不是第一反应。
六、小结
放行规则的黄金原则是”能细不粗、能限不限、能不就不”。优先用字段免检和条件组合，给放行加多重限制，并配合后端二次校验。记住：放行范围每扩大一分，安全风险就上升一分。
