请求通过网关，不代表请求本身就安全。理解API网关与应用层防护策略如何分工，关键是把入口可统一执行的规则交给网关，把依赖业务数据和上下文的判断留在应用层。比如创建订单的请求可以先经过网关的身份认证和速率限制，但商品是否可售、用户能否购买，仍须由应用程序核实。
网关负责统一入口，不负责替业务作决定
API网关位于客户端与后端服务之间，常见职责包括路由转发、TLS连接处理、令牌初步验证、请求体大小限制、访问日志和速率限制。像 NGINX、Kong、Envoy 等产品都可用于构建代理或网关能力；实际支持的功能和配置方式取决于部署版本与架构。
入口规则适合跨接口复用。例如，网关可以拒绝缺少有效凭证的请求，对异常高频调用返回 HTTP 429，或按路由限制请求体大小。这样能减少无效流量进入服务，也便于统一调整策略。不过，网关通常不知道某个用户是否拥有某条具体记录，因此不能仅凭“已登录”就允许读取数据。
应用层必须完成与业务有关的校验
认证通过不等于有权访问
应用层应依据当前用户身份、资源归属和操作类型作出授权判断。例如，用户请求读取 /users/42/profile 时，服务不能只确认令牌有效，还要判断该用户是否有权查看编号为 42 的资料。否则，即使网关正确完成身份认证，仍可能出现越权访问。
格式合法不等于业务有效
网关可以检查字段是否缺失、请求大小是否超限等通用条件；应用层还要检查字段之间的业务关系。以订单创建为例，数量必须符合库存规则，价格不能由客户端任意指定，订单状态也不能由请求直接改成已完成。此类判断依赖实时业务数据，应在执行操作的服务中完成，并在数据变更时再次确认。
按判断所需的信息划分控制点
实际设计API网关与应用层防护策略如何分工时，可以用一个问题作判断：执行规则是否需要理解具体资源、用户关系或业务状态？不需要的通用入口规则优先放在网关；需要访问业务数据才能判断的规则，应放在应用层。参数校验可以两边都有，但目的不同：网关做基础格式筛查，应用层做完整语义校验。
- 列出接口和风险：标明哪些接口公开、需要登录或会修改数据，并识别越权、重放和高频调用等风险。
- 配置入口防线：在网关设置路由、身份凭证初筛、速率限制、允许的方法及请求大小上限；具体阈值应结合正常流量和容量测试确定。
- 补齐服务端判断：在应用层验证资源归属、操作权限、字段范围和状态迁移，不信任客户端传来的用户编号、价格或角色。
- 测试绕行与失败场景：确认后端不能被公网绕过网关直接访问；再测试缺少凭证、访问他人资源、重复提交和无效状态变更等情况。
- 关联日志并复核：记录请求标识、路由、结果码及必要的用户信息，避免记录令牌等敏感凭证；根据告警和错误日志调整规则。
常见误区：把一层控制当成全部防护
仅在网关验证令牌，可能漏掉资源级权限；仅在应用中处理所有流量限制，则难以在流量到达服务前进行统一拦截。更稳妥的做法是分层：网关做身份认证初筛、速率限制和路由边界控制，应用层实施权限控制及参数校验。对于微服务，还应限制服务间访问，避免内部网络位置被误当作可信身份。
结论：入口过滤与业务校验缺一不可
API网关擅长统一、快速地处理入口流量，应用层则掌握判断用户、资源和业务状态所需的信息。落实API网关与应用层防护策略如何分工，不是二选一，而是让网关挡住通用风险，让应用服务对每次业务操作作最终授权与校验。
常见问题
网关已经验证令牌，应用还要验证吗？
要。应用仍需确认令牌对应的用户能否执行当前操作，并检查资源归属和业务权限。
参数校验应该放在哪一层？
基础格式、体积等规则可在网关筛查；字段含义、取值关系及业务约束应由应用层验证。
网关能否代替应用层做速率控制？
网关适合做统一入口限流；若限制规则依赖账户等级、资源状态或业务配额，还需应用层配合。
如何确认后端没有绕过网关？
检查网络访问规则和服务暴露方式，确保外部请求只能到达网关，并通过部署配置与访问日志持续复核。
