readObject

How readObject fits Java deserialisation

readObject is one of the few places where a class can intervene in Java deserialisation before an object is fully trusted by the runtime. That makes it part of the object lifecycle, not just a convenience hook: it can rebuild derived state, reapply defaults, and reject malformed input before the instance is exposed to application logic.

Because deserialisation reconstructs state from bytes supplied by another party or subsystem, the method effectively becomes a security boundary. If the implementation is too permissive, it may accept impossible combinations of field values, restore stale references, or bypass validation that constructors normally enforce.

Why validation inside readObject matters

A well-designed readObject method exists to restore invariants that serialization would otherwise bypass. Classes that rely on constructor-only checks, final fields, or derived relationships between fields need explicit validation during deserialisation, because the runtime can populate an object without using the normal construction path.

This is especially important for objects that represent security-sensitive state, such as permissions, tokens, policy objects, or references to shared resources. The method should treat incoming data as untrusted and verify that restored state still satisfies the class’s rules before the object is allowed to function.

Security implications of custom deserialisation hooks

Custom deserialisation logic can reduce risk when it narrows accepted state and restores consistency, but it can also expand attack surface if it performs complex work with attacker-controlled input. Any side effect beyond simple state repair increases the chance that malformed data will trigger unexpected behaviour during object reconstruction.

Implementations should be especially cautious when they restore object graphs, resolve external references, or interact with other code during deserialisation. The safer pattern is to validate first, reconstruct only what is necessary, and keep the method narrowly focused on state restoration rather than business logic.

When readObject becomes a maintenance and compatibility concern

readObject also creates long-term maintenance pressure because it ties a class’s internal representation to a specific serialisation format. Changes to fields, invariants, or object relationships can make older serialized data difficult to load safely unless the method is updated carefully.

That means the method is not only a deserialisation helper, but also part of the class’s compatibility contract. Teams that evolve serialized classes need to think about how legacy payloads will be interpreted, whether missing or extra fields should be tolerated, and how to prevent older data from restoring an unsafe state.

Risk and Threat Considerations

Custom deserialisation is a common place for logic flaws because the attacker controls the input shape and the runtime invokes the method automatically. If the method accepts untrusted object streams, a weak implementation can restore invalid state, trigger unexpected code paths, or contribute to deserialisation-based exploitation chains.

Failure mechanism: The object is rebuilt before its invariants are fully re-established, or the hook performs unsafe work while processing attacker-controlled serialized data. That can allow malformed payloads to slip past validation, or cause deserialisation to influence application behaviour in ways the class did not intend.

Impact: The result can be object corruption, authorization or integrity bypass within the application, and in some environments a broader remote code execution or denial-of-service risk if deserialisation is exposed to untrusted input.

Practitioner Guidance

Common misunderstanding: readObject is not a substitute for ordinary input handling, and it should not be used to perform general-purpose business processing. Its role is to restore a valid object state, verify invariants, and reject anything that cannot be safely represented.

What to watch for: review any class that implements custom deserialisation for hidden side effects, assumptions about trusted input, or a mismatch between constructor validation and post-deserialisation validation. Where serialized data can cross trust boundaries, keep the hook minimal and make the restored object fail closed if state is incomplete or inconsistent.