避免策略重复或漏配：API网关与应用层防护如何分工

讨论API网关与应用层防护策略如何分工，关键不是把安全措施平均分成两份，而是看规则依赖什么信息：只看请求来源、凭证或流量特征的，通常适合在网关统一处理；需要读取业务数据、判断操作含义的，应由应用层负责。边界不清，常见后果是两处重复校验，或误以为网关已经替应用做了授权。

先按判断依据划边界

网关位于请求进入后端服务的入口，可集中处理跨服务通用规则。例如 TLS 连接、路由、令牌初步验证、请求体大小上限、来源限制和基础限流。统一配置有利于快速拒绝明显异常流量，也避免每个服务各自维护一套入口规则。

应用层掌握业务规则和数据关系，负责判断请求能不能在当前状态下执行。身份认证只能说明请求者是谁，不能自动说明其有权操作某项资源。授权校验、状态转换、字段合法性等判断，应在实际执行业务的服务中完成。

以日历服务新增会议为例：网关可以验证令牌、限制单个账号的请求频率，并拒绝超过配置大小的请求；日历应用则要核对发起者是否有权使用目标日历、参会人是否符合规则，以及该时段是否与现有安排冲突。后几项会随日历数据变化，网关通常既没有完整数据，也不适合承担最终判断。

处理 GitHub webhook 时也类似：入口可限制请求方法、体积与来源范围；接收服务仍需按约定验证签名，并结合事件内容决定是否执行后续操作。仅凭请求成功到达网关，不应视为事件可信或业务操作已获授权。

列出防护规则。按身份认证、限流、请求约束、授权校验、业务状态检查分类，并标明规则所需数据来自哪里。
指定唯一责任方。跨服务且不依赖业务数据的规则优先放网关；依赖账户关系、资源状态或操作语义的规则交给应用。确需两层检查时，写清各自目的，例如网关限整体流量、应用限制某个具体动作。
定义拒绝行为。明确无效凭证、请求过大、权限不足和状态冲突分别如何处理，并保证应用不会把网关未执行的检查当作已完成。
用正反向用例验证。既测试正常请求，也测试缺失凭证、越权访问、重复提交和异常频率；检查请求经过不同路由或直接访问后端时，关键业务规则仍然有效。
统一维护与复核。网关规则和服务规则使用可追踪的配置、负责人及变更记录。接口或业务状态调整后，复核是否出现重复限流、旧权限判断或未覆盖的新入口。

这会让入口依赖业务数据，增加规则耦合；当不同服务对同一字段含义理解不同时，也容易出现误拦截。网关适合做通用筛查，不宜代替服务完成最终业务授权。

各服务重复实现 TLS、基础限流等能力，会造成策略不一致，也让明显异常请求更深入后端。网关统一入口规则的优点是集中管理，代价是配置必须谨慎，且不能成为唯一的业务安全边界。

因此，API网关与应用层防护策略如何分工，可归纳为：网关拦截通用、前置、跨服务的风险；应用层守住依赖业务上下文的最终决策。两层可以协作，但每条规则都应有明确责任方和验证方式。

应用可以信任经过明确配置的认证结果，但仍要检查该用户是否有权执行当前操作。对令牌签发方、受众和有效期等信任条件，也应有清晰约定。

不一定。网关适合限制入口总量或按账号、来源进行通用限流；应用层可对特定业务动作设置更细的额度或频率限制。

检查两处规则是否依据同一数据、阻止同一风险，并分别记录命中原因。若两处承担不同目的，应明确标注；若功能完全相同，可评估由一处负责执行，另一处仅保留必要的防御检查。