把请求拦在入口，不等于已经完成安全校验。讨论 API网关与应用层防护策略如何分工，关键是区分“请求能否进入”和“请求能否执行”：网关负责统一入口上的通用控制，应用负责理解业务语义并作出最终判断。两者应互补，而不是互相替代。
误区一：网关认证通过，应用就可以信任请求
网关可以验证令牌格式、签名和有效期，也可以拦截没有凭证的调用。但认证只回答“调用者是谁”，不自动回答“调用者能做什么”。例如，某个账号持有有效令牌，不代表它能修改所有项目的成员信息。应用仍须依据当前用户、资源归属和操作类型执行授权检查。
误区二：网关校验了参数，业务输入就安全
网关适合检查请求方法、路径、字段类型、必填项或请求体大小等通用条件。它通常不知道某个折扣是否仍有效、账户余额能否覆盖转账金额，也不知道两个字段组合后是否违反业务规则。应用层校验必须针对实际操作，在写入或产生副作用之前完成；不能只依赖前端表单或入口规则。
误区三：限流可以解决所有滥用
速率限制能控制单个来源或路由的请求速度，缓解突发流量和部分自动化滥用，但它不等于反欺诈，也不能识别所有低频异常。网关可按令牌、客户端或路由设置限流，并对超限请求返回适当的拒绝响应；应用还应关注账号级操作频率、重复提交和异常业务状态。阈值需结合正常流量、接口成本与峰值变化调整，不能照搬固定数字。
误区四：内网请求天然可信，校验只需放在网关
服务之间的调用也可能因配置错误、凭证泄露或某个服务被攻陷而越权。网关之外的内部接口仍应验证调用身份，并按最小权限授予访问范围。应用收到的数据也不能因为“来自内网”就跳过字段校验、资源授权和状态检查。网络边界能降低暴露面，不能代替每个服务的安全判断。
误区五：有网关日志，就足以排查安全问题
网关日志适合记录路由、响应状态、耗时、来源和限流结果；但它通常看不到应用内的授权决策、业务对象变化及失败原因。应用应记录必要的操作事件，并通过请求标识关联入口与服务日志。日志中避免直接保存访问令牌、密码等敏感内容；同时设置访问权限和保留周期，减少日志本身带来的泄露风险。
按责任边界落地：先分层，再验证
- 列出入口控制：在网关配置路由、TLS处理、凭证初步验证、请求大小限制、基础限流和统一访问日志。
- 列出应用判定：为每项接口明确身份、资源权限、字段约束、业务状态和数据变更规则，由应用在执行操作前核验。
- 约定失败处理：区分未认证、无权访问、参数不合法和业务条件不满足，返回一致且不过度暴露内部细节的错误信息。
- 做绕行测试：确认服务端口不能被非预期路径直接访问；若内部调用允许绕过网关，应用仍须独立验证身份与权限。
- 关联日志并复测：用请求标识串联网关和应用记录，再测试无凭证、越权资源、畸形字段、重复操作及超限请求，确认每一层都按职责拒绝。
判断 API网关与应用层防护策略如何分工，可以记住一条原则：网关执行跨接口一致的入口政策，应用执行依赖用户、资源和业务状态的决定。网关失效时，应用关键校验仍应成立；应用规则变化时，也不应把复杂业务判断塞进入口配置。
常见问题
网关能不能做身份认证？
可以承担统一认证或凭证初步验证，但应用仍需确认调用身份与具体资源、操作之间的授权关系。
参数校验应该放在哪一层？
请求格式、大小等通用检查可放在网关；字段含义、资源归属和业务规则由应用最终校验。必要时两层都检查，但应用不能省略。
内部服务是否需要再次校验？
需要。内部网络不是可信身份凭证，服务仍应验证调用来源、权限和输入，并限制直接绕过入口的访问。
小型系统是否必须部署 API 网关？
不一定。部署与否取决于路由数量、统一策略需求和运维能力；无论是否使用网关，应用层授权与业务校验都不可缺少。
