Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When a class implements Serializable and does not override its functionality, it is said to be using the default serialized form. If the class changes in the future, any byte stream produced by users of the old class will not be compatible with the new implementation. Moving to a custom serialized form releases the implementer from the trap of having to maintain the original serialized form as well as the corresponding version of the class.

Noncompliant Code Example

This noncompliant snippet implements a GameWeapon class with a serializable field called noofWeapons, and uses the default serialization form. Any changes to the internal representation of the class can break the existing serialized form.

Code Block
bgColor#FFcccc
class GameWeapon implements Serializable {
  int noofWeapons = 10;
	    
  public String toString() {
    return String.valueOf(noofWeapons);
  }
}

Compliant Solution

Ideally, implement Serializable only when the class is not expected to evolve frequently. One way to maintain the original serialized form, at the same time allowing the class to evolve is to use custom serialization with the help of serialPersistentFields. The static and transient fields allow you to specify what should not be serialized whereas the serialPersistentFields field specifies what should be serialized. It also relieves the class from defining the serializable field within the class implementation, thus decoupling the current implementation from the logic. New fields can easily be added without breaking compatibility across releases.

...

Inner classes can only contain final static fields that are initialized to constants or expressions built up from constants. Consequently, it is not possible to set serialPersistentFields for an inner class (though it is possible to set it for static member classes).

Finally, serialization is easy to get wrong and must therefore be carefully designed.

Risk Assessment

Failure to provide a consistent serialization mechanism across releases can limit the extensibility of classes. If classes are extended, a can of compatibility vulnerabilities may get introduced.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER00-J

low

probable

high

P2

L3

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

Wiki Markup
\[[API 06|AA. Java References#API 06]\]
\[[Sun 06|AA. Java References#Sun 06]\] "Serialization specification", "1.5  Defining Serializable Fields for a Class" and "1.7  Accessing Serializable Fields of a Class"
\[[APIBloch 0608|AA. Java References#APIReferences#Bloch 0608]\] Item 74: "Implement serialization judiciously"

...

11. Serialization (SER)      11. Serialization (SER)      11. Serialization (SER)