WAF 白名单与例外设计是什么
白名单（例外）是让某个具体的检测点不再拦截某类请求，是误报治理的必要手段，也是防护被削弱的地方。设计原则只有一条：范围越小越安全。理想的写法精确到「某条规则 + 某个 URL + 某个参数 + 某个来源」，而不是按路径前缀或整站关闭。粗放白名单会在防护上留下永久通道——攻击者只要能访问被放开的路径，就能绕过 WAF 的检查。
基本信息
| 粒度维度 | 规则 + URL + 参数 + 来源 IP + HTTP 方法 |
|---|---|
| 审批流程 | 业务确认业务需求，安全复核例外范围 |
| 复核机制 | 每条例外设置复核日期与责任人 |
| 记录内容 | 规则标识、路径、参数、原因、设置与审批人 |
| 替代手段 | 优先修正应用行为或调整规则阈值，其次才加例外 |
典型使用场景
- 富文本编辑器提交内容含 HTML 标签，触发跨站类规则误拦
- 文件上传接口的二进制内容被当作异常载荷拦截
- JSON 或 XML 接口参数中含有类 SQL 关键字，造成误判
- 运维与监控平台的健康检查请求频率或特征触发规则
- 内部管理后台需要放行特定来源地址，避免被频率规则限制
- 旧接口无法改造时的过渡处理：先精确开例外，同时排期整改
例外设计对比
例外设计对比
# 较好：仅对某条规则、某个 URL 的某个参数关闭检测
# 规则 xxx：/api/editor/save 的 content 参数不参与检测
# 较差：整个 /api/ 路径关闭全部检测 → 同前缀接口全部暴露
# 更差：整站关闭 WAF 防护 → 等于撤掉防护
# 例外记录：原因、业务确认人、设置人、复核日期必填
# 复核动作：到期确认应用是否已修正，能取消即取消例外范围对照
| 写法 | 影响面 | 建议 |
|---|---|---|
| 规则 + URL + 参数 | 仅一个检测点 | 优先采用 |
| 规则 + URL | 该 URL 的该规则全部关闭 | 次选，需说明理由 |
| 整条路径关闭检测 | 路径下所有接口失去该层防护 | 仅短期过渡并限期整改 |
| 整站关闭防护 | 站点完全裸奔 | 严禁，除应急并限时 |
严禁整站关闭防护类例外；确有紧急需求时应按评审流程执行，并且设置明确的恢复时间与责任人。
例外需要与接口变更同步维护：接口参数结构改了，原例外的适用范围可能失效，误报会重新出现，因此例外的复核日期要真正执行。