白名单只列“允许访问的地址”，看似简单，却容易因路径过宽或权限混用而放行不该通过的请求。有效的Web访问控制策略白名单设计，应先还原用户完成任务时经过的业务路径，再逐段定义谁能以什么方式访问哪些资源，而不是把一个站点或一组目录整体设为可信。
先把业务流程拆成访问节点
以一个常见的订单管理流程为例：用户登录后查看订单详情，符合条件时再取消订单，最后可能导出清单。这些操作虽属于同一业务，却有不同风险。查看通常是读取，取消会改变状态，导出还可能批量带出数据。因此，规则应按用途分开，而不应仅凭“都在订单页面”给予相同权限。
可以先画出路径图，标明每一步使用的页面或接口、请求方法、所需角色、可访问的数据范围，以及操作成功的前置条件。路径图不需要复杂工具，表格也能完成；关键是把正常流程和管理、维护等例外流程分开记录。
把白名单拆成可核对的规则层
入口、路径与方法分别限定
一条规则至少应考虑访问入口、主机或应用、路径、HTTP 方法和身份权限。例如，示意规则可允许已登录用户以 GET 访问 /orders/{id}，但只允许具备相应职责的用户以 POST 执行 /orders/{id}/cancel。示例路径用于说明规则结构，不代表任何特定系统的实际接口。
路径匹配越宽，误放行的可能性越高。精确匹配适合固定页面或操作入口，维护成本较低；带变量的路径适合订单编号等动态资源，但还需校验当前用户是否有权访问该编号对应的对象。目录前缀规则便于管理，却可能连带允许新增加的敏感页面，只有在目录下各项功能权限一致、且能持续审查时才适用。
角色、数据范围和操作类型不要合并
仅凭登录状态放行，无法区分普通查看与高风险变更。将角色权限与资源范围一并核对，例如用户是否负责该订单、该记录是否处于允许取消的状态。遵循最小权限原则：规则只覆盖完成当前任务所需的请求，不顺手开放相邻路径、其他方法或全部记录。
从盘点到上线：五步落地
- 列出现有入口。从页面导航、接口文档、服务器路由配置和访问日志中整理真实使用的路径与方法；日志只能帮助发现请求，不能单独证明请求应获准。
- 按业务路径分组。分别标记登录、查询、修改、导出等节点，写明角色、资源范围和前置条件。对暂时无法确认用途的入口先保持受限，交由业务负责人核实。
- 编写具体规则。明确允许条件和拒绝条件，避免“允许所有已登录请求”之类概括规则。没有匹配到允许规则时采用默认拒绝，并记录被拒绝的路径、方法及时间，供排查误拦截。
- 测试正常与越权场景。既验证正确角色能走完流程，也验证错误方法、无关角色、他人资源编号、缺少前置步骤等请求会被拒绝。还要检查路径大小写、尾部斜杠、编码字符及重定向处理是否与实际路由一致。
- 小范围发布并复核。先在测试环境或有限范围内观察日志，再扩大启用范围。每次新增页面、接口或角色时，重新检查受影响规则；移除已不再使用的例外，避免白名单随时间不断膨胀。
重点检查容易藏在规则边缘的风险
配置时要确认网关、反向代理和应用对路径的解析方式一致。若前置设备按一种形式匹配，而应用将编码字符或重复分隔符解析成另一条路由，单看白名单文本可能得出错误判断。不要假设所有系统都会以相同方式处理这些输入，应针对实际部署做测试。
还要检查同一路径的不同 HTTP 方法、批量导出入口、文件下载和管理操作是否被宽泛规则一并覆盖。访问日志中出现高频请求，不等于应该扩大白名单；先确认它属于哪条业务路径、是否来自预期身份，再决定调整策略。这样，Web访问控制策略白名单设计才既能支持正常操作，也能让例外有据可查。
常见问题
只按域名配置白名单可以吗？
域名适合限制访问目标，但无法表达同一站点内不同页面和操作的权限差异。对应用内访问控制，还应细分路径、方法和身份。
路径前缀规则一定不安全吗？
不一定。若前缀下功能权限相同且变更有人复核，可以使用；若包含查询、修改等不同风险操作，宜缩小匹配范围或拆分规则。
白名单没有命中时应怎样处理？
通常应拒绝并记录必要信息，再由负责人确认是否属于遗漏的正常业务。不要为消除告警直接改成宽泛放行。
规则调整后需要重新测试吗？
需要。至少回归测试受影响的正常流程与越权场景，并核对路径解析、角色权限和资源范围。持续复核是Web访问控制策略白名单设计的一部分，而非一次性配置任务。
