PG官网

  微服务架构里，网关是所有请求的入口，统一在这里做身份校验，是很主流的方案。不用每个业务服务单独写一套登录解析代码，新增接口也只需要在网关配置白名单，看起来省心很多。但我们团队曾经吃过亏，以为把鉴权放到网关就万事大吉，结果一次安全扫描，直接发现接口可以绕过网关校验。

  问题根源是路径匹配规则。当时配置的是Ant路径匹配，想保护/api/user/**，开放/api/login的登录接口。开发忽略匹配规则的细节，特殊后缀、大小写、多余斜杠这类变形请求，直接跳过网关鉴权，请求直达后端业务服务。后端接口本身没有二次校验，匿名用户就能访问敏感数据。

  很多人会陷入一个误区：网关做了鉴权，后端服务就可以完全信任请求。实际上网关只是外层防护，一旦网关配置出错，或者网络层面请求绕过网关，后端就毫无防护能力。核心业务接口，后端最好保留轻量的权限校验，不能完全依赖网关。

// 危险示例：网关路径匹配容易踩坑
// 配置 /api/user/**
// 但 /api/user/./info、/api/user//info 这类路径会出现匹配异常
// 尽量使用精确匹配，谨慎使用通配符

  Token处理也是一大隐患。不少项目把JWT放在URL参数里传递，方便调试，上线之后忘记修改。访问日志会完整记录URL，Token直接留在访问日志中，一旦日志泄露，攻击者就能拿到用户身份，冒充用户操作。Token务必放在请求Header里传输，不要放在query参数。

  还有Token缓存的问题。网关解析JWT之后，会把用户信息缓存下来，减少重复解析开销。但缓存过期时间和Token过期时间不一致，就会出现Token已经过期，网关缓存里的用户信息依旧有效，请求继续放行。用户退出登录之后，Token没有即时失效，这也是很多系统会话控制的痛点。JWT本身无状态，想要实现主动下线，单纯依靠原生JWT很难做到，需要引入黑名单或者分布式缓存记录失效凭证。

  越权问题，和鉴权逻辑强相关。网关大多只校验用户是否登录，很少去校验用户能不能操作当前资源。同一个接口，A用户和B用户都能访问，网关只判断有没有登录，资源归属校验交给业务服务。一旦业务代码漏写资源归属判断，水平越权就会出现。

  很多开发以为，登录校验等于权限校验。登录只是确认“你是谁”，权限校验确认“你能不能操作这个资源”，网关适合做前者，后者大多需要业务数据判断，放在网关很难实现。如果把细粒度权限全部压在网关，配置会变得极其复杂，维护成本极高。

  请求转发时的Header处理也不能忽视。网关解析完身份，把用户ID放到请求头向下游传递。如果没有过滤原始请求的Header，用户可以自己在请求里伪造user-id头，直接传递给后端，后端读取Header当作可信身份，造成身份伪造。所有网关向下游透传的身份相关Header，必须清理客户端传来的同名字段，只允许网关自己写入。

# 网关转发配置示例，清除客户端伪造的身份头
spring:
  cloud:
    gateway:
      routes:
        - id: user-route
          uri: lb://user-service
          filters:
            - RemoveRequestHeader=X-User-Id
            - AddRequestHeader=X-User-Id, #{userContext.userId}

  会话复用和多端登录的场景，同样需要考虑。用户在手机端登录，网页端下线，如果没有统一会话管理，旧Token依旧可以使用。网关可以在鉴权阶段查询分布式缓存，校验当前token是否处于已注销状态，实现主动失效。

  在网关做鉴权，还有限流、日志审计的配套工作。所有鉴权拒绝的请求，都要留存日志，记录IP、账号、请求路径，方便事后追溯。同时针对登录接口、Token刷新接口做限流，防止暴力破解。

  排查网关鉴权类漏洞，不能只拿正常账号测试。要尝试构造特殊路径、修改请求头、过期Token，模拟各种异常场景。重点测试白名单接口，很多安全事故都出在白名单配置遗漏。上线前，单独针对路由规则做安全审计，逐条核对接口开放范围。

  网关统一认证的本质，是增加一层防护，而不是把安全责任全部转移到网关。它擅长身份识别、请求拦截、基础的流量控制，但细粒度资源权限、业务级数据校验，依然要下沉到业务服务。

  很多安全问题不是复杂的漏洞，只是配置疏忽、对转发机制理解不到位。路径匹配、请求头透传、Token传输方式，这些不起眼的细节，恰恰是最容易突破的入口。理清网关和后端各自的安全职责，分层防护，才能避免一着不慎，整个体系被击穿。