最根本的防护是绝不反序列化不可信渠道的数据；必须启用类白名单、禁用高风险框架配置，并优先采用json、protobuf等无动态类加载能力的安全替代方案。
只反序列化可信来源的数据
反序列化漏洞的根源在于程序盲目信任外部输入。Java 的 ObjectInputStream.readObject() 会自动加载类、调用构造函数、readObject() 方法、静态代码块甚至 finalize()，这些都可能被恶意触发。因此，最根本的防护是：**绝不反序列化来自用户输入、HTTP 请求体、消息队列、文件上传、第三方 API 响应等不可信渠道的数据**。如果业务逻辑确实绕不开（如某些 RPC 框架或遗留系统），必须先确认数据来源是否经过身份认证、传输加密和访问控制，且该通道本身不向攻击者开放写入权限。
启用类白名单机制
当无法完全规避反序列化时，必须限制可加载的类范围。Java 原生不提供白名单，但可通过自定义 ObjectInputStream 子类实现：
- 重写 resolveClass(ObjectStreamClass desc) 方法
- 检查 desc.getName() 是否在预设的安全类列表中（如仅允许
java.lang.String、com.example.dto.User等业务实体） - 对不在白名单中的类直接抛出 InvalidClassException
注意：白名单需严格维护，避免包含已知危险类（如 org.apache.commons.collections.functors.InvokerTransformer）或反射/运行时相关类（如 java.lang.Runtime、javax.naming.InitialContext）。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
禁用高风险框架配置
许多第三方库默认开启危险特性，需主动关闭：
-
Jackson-databind：禁用 enableDefaultTyping()，改用显式类型声明（如
mapper.readValue(json, MyDto.class)）；升级至安全版本（2.9.x ≥ 2.9.10.8，2.10.x ≥ 2.10.5.1，2.11.x ≥ 2.11.3） -
Fastjson：禁用 autoTypeSupport（默认从 1.2.68 起关闭），升级到 1.2.83+；避免使用
JSON.parseObject(json, Object.class)这类泛型反序列化 - Apache Commons Collections：升级到 4.0+（彻底移除危险链式调用类），或确保不引入 3.x 版本
使用更安全的替代方案
能不用 Java 原生序列化就尽量不用。推荐转向语义明确、无动态类加载能力的格式：
- HTTP 接口统一用 JSON（Jackson/Gson）或 Protobuf，配合严格 Schema 校验
- 内部服务通信优先选 gRPC（基于 Protobuf）或 Dubbo 的 Hessian2（需确认已禁用反序列化执行路径）
- 持久化场景用数据库字段映射或标准 ORM（如 MyBatis、JPA），而非将整个对象 dump 成二进制存文件
这些方案天然规避了类名解析与任意类实例化过程，从设计上切断反序列化漏洞的利用链条。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
