Making defensive copies of mutable method parameters mitigates against a variety of security vulnerabilities; see OBJ06-J. Defensively copy mutable inputs and mutable internal components for additional information. However, inappropriate use of the clone method can allow an attacker to exploit vulnerabilities by providing arguments that pass initial validation but subsequently return unexpected values. Such objects may consequently bypass validation and security checks. Never use the clone method () method of nonfinal classes to make defensive copies of objects that are instances of classes that both are nonfinal and provide a clone() method. So never use the clone method for defensive copying of untrusted method parameters.
...
The storeDateInDB() method accepts an untrusted date argument and attempts to make a defensive copy using the clone() method. This allows an attacker to take control of the program by creating a malicious date class that extends Date and whose clone() method carries out the attacker's wishes. Then the perpetrates the attack by failing to provide proper copy functionality. The attacker creates an object of this type and passes it to storeDateInDB() so that the validation succeeds the first time and subsequently mutates the date to a value of his choice.
Compliant Solution
This compliant solution avoids using the clone method. Instead, it creates a new java.util.Date object that is subsequently used for access control checks and for insertion into the database:
...