Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

Code Correctness: Incorrect Serializable Method Signature

Abstract
Using the incorrect method signature on a method used in serialization may lead to it never being called.
Explanation
Code Correctness: Incorrect Serializable Method Signature issues occur when a serializable class creates a serialization or deserialization function but does not follow the correct signatures:


private void writeObject(java.io.ObjectOutputStream out) throws IOException;
private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
private void readObjectNoData() throws ObjectStreamException;


Deviating from the method signatures that serialization requires may mean that the method is never called during serialization/deserialization, leading to incomplete serialization/deserialization, or could mean that untrusted code could gain access to the objects.
In the case that there are exceptions that are not thrown, it may mean that serialization/deserialization fails and crashes the application or potentially even fails quietly such that objects may be only partially constructed correctly, leading to flaws that can be extremely difficult to debug. The caller should catch these exceptions such that incorrect serialization/deserialization can be handled properly without a crash or partially constructed objects.
References
[1] SER01-J. Do not deviate from the proper signatures of serialization methods CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
desc.structural.java.code_correctness_incorrect_serializable_method_signature