Every serializable container class that has private mutable instance variables must defensively copy them in the readObject() method. An adversary can append tamper with the serialized form of such a class, appending extra references to the variables to generate a new byte stream. When deserialized, this byte stream allows could allow the creation of a container class instance whose internal variable references are controlled by the attacker-controllable. Consequently, this allows the instance of the container class to mutate and violate its guaranteesclass invariants.
This rule is an instance of OBJ14-J. Defensively copy mutable inputs and mutable internal components. Whereas that rule applies to constructors, and other methods that take untrusted mutable parameters, this rule applies the same principle to deserialized mutable fields.
Noncompliant Code Example
This noncompliant code example lacks defensive copying of the mutable components or sub-objects (the date object in this case) date object, which is mutable. An attacker may be able to create an instance of MutableSer for which all invariants hold when validation is carried out that later mutates the value of the date sub-object to violate the class's contract whose date object contains a nefarious subclass of Date whose methods can do the attacker's bidding. Any code that depends on the immutability of the sub-object is vulnerable.
...
This compliant solution creates a defensive copy of the mutable Date date object in the readObject() method. Note the use of field-by-field input and validation of incoming fields (see guideline SER04-J. Validate deserialized objects for additional information). Additionally, note that this compliant solution is insufficient to protect sensitive data (see guideline SER03-J. Do not serialize sensitive data for additional information).
...