...
Additionally, returning references to an an object's internal mutable components provides an attacker with the opportunity to corrupt the state of the object. Accessor methods must consequently return defensive copies of internal mutable objects; see guideline rule OBJ09-J. Defensively copy private mutable class members before returning their references for additional information.
...
This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable interface and declaring a public clone method (for classes not declared as final). In cases like HttpCookie where the mutable class is declared final — that is, it cannot provide an accessible copy method — perform a manual copy of the object state within the caller. See guideline rule OBJ08-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely for more information. Note that any input validation must be performed on the copy and not on the original object.
...
You must make defensive copies of all mutable inputs to comply with this guidelinerule. Some copy constructors and clone() methods perform a shallow copy of the original instance. For example, invocation of clone() on an array results in creation of an array instance whose elements have the same values as the original instance. This shallow copy is sufficient for arrays of primitive types, but fails to protect against TOCTOU vulnerabilities when the elements are references to mutable objects. Use a deep copy that performs element duplication when the input consists of mutable components, such as an array of cookies.
...
Search for vulnerabilities resulting from the violation of this guideline rule on the CERT website.
Bibliography
...