skip to content

What are the security and schema-evolution risks of native Java serialization, and how do you mitigate them?

level: principalimportance: should knowfreq 40%

answer

  1. readObject runs code -> gadget chains -> RCE
  2. Rule: never deserialize untrusted data
  3. JEP 290 ObjectInputFilter allow-list + limits
  4. serialVersionUID drift breaks old streams
  5. Prefer schema-based versioned formats (protobuf/Avro/JSON)

basics

~20 s

Deserializing untrusted bytes can let an attacker run code on your machine, and changing a class can break old saved data. Avoid deserializing untrusted input, use input filters, and prefer schema-based formats like JSON or Protocol Buffers.

solid answer

~50 s

Native Java deserialization is dangerous because readObject reconstructs arbitrary object graphs and runs class logic (readObject hooks, finalizers, side effects in libraries on the classpath). Attackers chain these 'gadgets' to achieve remote code execution from a crafted byte stream — so the core rule is: never deserialize untrusted data. Mitigations: use the JEP 290 deserialization filter (ObjectInputFilter) to allow-list expected classes and cap depth/size; keep gadget-prone libraries off the classpath; run with least privilege. On the evolution side, serialization is brittle: structural changes alter the auto-computed serialVersionUID and break old streams, and there's no real migration story. Declare serialVersionUID explicitly, treat the serialized form as a public API, and use writeObject/readObject carefully. For most systems the right answer is to avoid native serialization entirely for persistence or wire formats and use a versioned, schema-based format (Protocol Buffers, Avro, JSON) with explicit compatibility rules.

code

java · 7 lines
java
// Lock down a stream with a JEP 290 allow-list filter
ObjectInputStream in = new ObjectInputStream(source);
in.setObjectInputFilter(ObjectInputFilter.Config.createFilter(
        "com.example.Trusted;java.base/*;maxdepth=10;maxarray=1000;!*"));
// 'com.example.Trusted' allowed, core java.base allowed, everything else (!*) rejected,
// with caps on graph depth and array size.
MyType x = (MyType) in.readObject();

go deeper

for a junior

Knows that deserializing data from untrusted sources can be unsafe and that you shouldn't do it casually.

for a middle

Can state the 'never deserialize untrusted input' rule, knows serialVersionUID controls version compatibility, and that JSON/other formats are common alternatives.

for a senior

Explains gadget-chain RCE, why type expectations don't protect you, JEP 290 filtering with allow-lists and limits, and serialVersionUID/evolution brittleness with concrete mitigations.

for a principal

Sets organizational policy (no native deserialization across trust boundaries, schema-based versioned formats by default), governs the gadget-surface via dependency management, and plans migrations off legacy serialized formats with compatibility guarantees.

## Two distinct risk families Native Java serialization (`ObjectOutputStream`/`ObjectInputStream`) carries two separate categories of risk: **security** (deserializing hostile bytes) and **schema evolution** (changing a class breaks old data). Both are serious enough that modern guidance is to avoid native serialization for any untrusted or long-lived data. ## Security: why deserialization is dangerous Deserialization is not a passive 'parse some bytes' operation. `readObject` **constructs live objects** and, while doing so, executes code: - A class's private `readObject(ObjectInputStream)` hook runs. - `readResolve`/`validateObject` run. - Side effects can fire as objects are built, and object `finalize`/cleanup can run later. The attack technique is the **gadget chain**. The byte stream names which classes to instantiate. An attacker crafts a stream that instantiates a sequence of classes already on your classpath whose `readObject`/getter/setter logic, when wired together, performs something dangerous — ultimately **remote code execution (RCE)**. Famous gadget chains used common libraries (e.g. certain Commons-Collections versions). The critical point: **the vulnerability is the act of deserializing attacker-controlled bytes**, even into a type you 'expected', because the stream chooses the concrete classes. This is why the absolute rule is: **never deserialize data you don't fully trust.** ### Mitigations 1. **Don't deserialize untrusted input at all.** Best mitigation by far. Use a data format (JSON/protobuf) that only produces inert data, not arbitrary live objects. 2. **Deserialization filters (JEP 290).** Java added `ObjectInputFilter`: you install a filter (per-stream, per-process, or via system property) that is consulted for every class about to be resolved. Use it to **allow-list** the exact classes you expect and to **cap** graph depth, array sizes, references, and total bytes — rejecting anything else before it is instantiated. A context-specific allow-list is far safer than a deny-list. 3. **Reduce the gadget surface.** Keep known gadget-prone libraries off the classpath / keep dependencies patched. 4. **Least privilege & isolation.** Run the deserializing code with minimal permissions and, where possible, in an isolated process. ## Schema evolution: why serialization is brittle The **serialized form** of a class is effectively part of its public contract. Problems: - **serialVersionUID drift.** If you don't declare a `serialVersionUID`, the runtime computes one from the class's exact structure (fields, methods, etc.). Almost any change — adding a field, changing a modifier — changes the computed UID, so old streams fail with `InvalidClassException`. - **No migration framework.** Java's default mechanism has only limited compatible-change rules (you can add fields and they default on read; you can't freely rename/retype). There is no first-class versioning/migration story like schema registries provide. - **Tight coupling.** Both writer and reader must share compatible class definitions; this couples persisted data or network peers to your code's internal structure. ### Mitigations 1. **Declare `serialVersionUID` explicitly** (`private static final long serialVersionUID = 1L;`) so *you* decide what's compatible, not the compiler. 2. **Treat the serialized form as an API**: document it, change it deliberately, and use custom `writeObject`/`readObject` or `serialPersistentFields` to control the layout. 3. **Prefer a schema-based, versioned format.** Protocol Buffers, Avro, Thrift, or even disciplined JSON give explicit forward/backward-compatibility rules, language interoperability, and (with Avro) schema registries. For new persistence or wire protocols, this is almost always the better choice. ## The principal-level takeaway Native serialization is convenient and shows up in legacy systems, RMI, and some caches, so you must understand it. But as an architectural default it is a poor choice for anything crossing a trust boundary or living a long time. Set a team policy: **no native deserialization of untrusted input; schema-based versioned formats for persistence and wire**; if native serialization is unavoidable, lock it down with `ObjectInputFilter` allow-lists and explicit `serialVersionUID`.

  • Why isn't 'I cast the result to the type I expect' enough to make deserialization safe?
    The cast happens after objects are constructed. The byte stream itself dictates which classes get instantiated, and their readObject/side-effect logic runs during construction — RCE can occur before your cast ever executes.
  • What does an ObjectInputFilter (JEP 290) let you do?
    It is consulted for each class/array about to be deserialized, letting you allow-list expected classes and reject everything else, and cap graph depth, array length, reference count, and stream size — blocking hostile graphs before instantiation.

saying these in an interview costs you the question

  • Believing deserialization is a safe, passive parse that can't run code.
  • Thinking declaring the expected type makes deserializing untrusted bytes safe — the stream picks the concrete classes.
  • Relying on a deny-list of classes instead of an allow-list.
  • Assuming serialization handles arbitrary class changes gracefully.
  • Treating the serialized form as a private implementation detail you can change freely.

context

resolving links…