Deserializing untrusted data can cause Java to create an object of an arbitrary attacker-specified class, provided that the class is available on the classpath specified for the JVM. Some classes have triggers that execute additional code when they are created in this manner; see SEC58-J. Deserialization methods should not perform potentially dangerous operations by default for more information. If such classes are poorly designed, such code could even invoke arbitrary methods, such as Runtime.exec() with an attacker-supplied argument. Therefore, untrusted input to be deserialized should be first validated to ensure that the serialized data contains only trusted classes, perhaps specified in a whitelist of trusted classes. This can be done by overriding the resolveClass() method of the java.io.ObjectInputStream class.
This rule applies only to untrusted data. Data that does not cross a program's trust boundary is, by definition, trusted and can be deserialized without violating this rule. See the exception SER12-EX0 for more information.
Data that is trusted, but must cross a trust boundary (perhaps because it originates from a different host) should be signed and sealed to maintain its trust. See SER02-J. Sign then seal objects before sending them outside a trust boundary for more information.
Non-Compliant Code Example
...