微服务网关应禁用高危反序列化机制，仅用树模型或字符串解析提取必要字段，强制输入格式白名单校验，透传原始载荷而非重建对象，并通过JVM参数、serialFilter及Agent工具加固运行时防护。
微服务网关是流量入口，也是反序列化风险的“第一道防线”。它不直接处理业务逻辑，但若盲目反序列化下游服务所需的请求载荷（如 JSON、二进制协议体），就极易成为 Fastjson、Jackson、Kryo 或 Java 原生反序列化的攻击跳板。安全的关键不是“能不能反序列化”，而是“在什么条件下、以什么方式、反序列化什么”。
明确反序列化边界：只解码，不重建对象图
网关的核心职责是路由、鉴权、限流和协议转换，不是业务对象构造器。因此应避免使用任何会触发完整对象重建的反序列化方式：
- 禁用
ObjectInputStream.readObject()、XMLDecoder.readObject()等原生/高危反序列化入口 - 禁用 Jackson 的
enableDefaultTyping()、@JsonTypeInfo(use = Id.CLASS)等开放类型推断机制 - 禁用 Fastjson 的
AutoType（尤其 1.x 版本），Fastjson 2.x 也需显式关闭：ParserConfig.getGlobalInstance().setSafeMode(true) - 对 JSON 载荷，优先使用 树模型（JsonNode）或字符串解析，仅提取路由、鉴权、限流所需字段（如
tenantId、userId、apiVersion），不映射到任意 POJO
强制输入格式与结构白名单
网关必须对上游输入施加强约束，不能依赖下游服务的“信任假设”：
- 只接受已知 MIME 类型：如
application/json、application/x-www-form-urlencoded，拒绝application/octet-stream、application/java-serialized-object等高危类型 - 对 JSON 请求，启用 JSON Schema 校验：定义字段名、类型、长度、正则格式（如
userId必须为 8–32 位字母数字） - 对 Protobuf/Thrift 等二进制协议，校验
message的type_url是否在预注册白名单内，并限制 payload 总长度（防堆溢出） - 拒绝含
@type、$type、javaClass、class等敏感键名的 JSON 字段（可配置 WAF 规则拦截）
隔离与降级：让反序列化远离核心路径
即使需将部分载荷透传给下游，也不应在网关层完成完整反序列化：
立即学习“Java免费学习笔记（深入）”；
- 将原始请求体（
byte[]或String）以“不可执行”的形式缓存或透传，由下游业务服务在受控上下文中处理 - 对需要轻量解析的场景（如提取 JWT 中的
scope），使用专用、无反射、无类加载的解析器（如jjwt-api解析 token，而非用 Jackson 反序列化整个 header/payload） - 配置熔断策略：当某接口连续出现反序列化异常（
InvalidDefinitionException、MismatchedInputException、InvalidClassException），自动标记为可疑并临时拦截 - 日志脱敏：记录反序列化失败时的请求 ID、HTTP 方法、路径、状态码，但绝不记录原始载荷或类名（防信息泄露）
运行时防护加固
防御需纵深覆盖，网关 JVM 层也要设防：
- 在启动参数中添加
-Dsun.rmi.registry.disableRegistry=true -Dcom.sun.jndi.ldap.object.trustURLCodebase=false，阻断 JNDI 远程加载路径 - 使用 Java Agent 工具（如 ysoserial 对应的检测插件）监控
ObjectInputStream调用栈，发现非预期调用立即告警或中断 - 升级至 JDK 17+，利用
jdk.serialFilter全局白名单机制（如-Djdk.serialFilter=java.util.ArrayList;java.lang.String;!*）限制可反序列化类 - 若使用 Spring Cloud Gateway，禁用
RoutePredicateFactory中所有基于反射解析 body 的自定义断言；改用ServerWebExchange.getFormData()或exchange.getRequest().getBody()流式读取
