Page History

Mutable classes allow code external to the class to alter their instance or class fields. Provide means for creating copies of mutable classes so that disposable instances of such classes can be passed to untrusted code. This functionality is useful when methods in other classes must create copies of the particular class instance; see rules "OBJ06-J. Defensively copy mutable inputs and mutable internal components" and "OBJ05-J. Defensively copy private mutable class members before returning their references" for additional details.

Mutable classes must provide either a copy constructor or a public static factory method that returns a copy of an instance. Alternatively, final classes may advertise their copy functionality by overriding the clone() method of java.lang.Object. Use of the clone() method is secure only for final classes; non-final nonfinal classes must not take this approach.

Trusted callers can be trusted to use the provided copy functionality to make defensive copies before passing object instances to untrusted code. Untrusted callers cannot be trusted to make such defensive copies. Consequently, providing copy functionality does not obviate the need for making defensive copies of inputs received from , untrusted code or outputs returned to , untrusted code.

Noncompliant Code Example

...

When a trusted caller passes an instance of MutableClass to untrusted code, and the untrusted code modifies that instance (perhaps by incrementing the month or changing the timezone), the object's state of the object can be made inconsistent with respect to its previous state. Similar problems can arise in the presence of multiple threads, even in the absence of untrusted code.

...

When untrusted code can call accessor methods passing mutable arguments, create defensive copies of the arguments before they are stored in any instance fields. See rule "OBJ06-J. Defensively copy mutable inputs and mutable internal components" for additional information. When retrieving internal mutable state, make a defensive copy of that state before returning it to untrusted code. See rule "OBJ05-J. Defensively copy private mutable class members before returning their references" for additional information.

Defensive copies are would be unnecessary if untrusted code always invokes invoked an object's clone() method on a mutable state received from mutable classes and operated only on the cloned copy. Unfortunately, untrusted code has little incentive to do so, and malicious code has every incentive to misbehave. This compliant solution provides a clone() method to trusted code and also guarantees that the state of the object cannot be compromised when the accessor methods are called directly from untrusted code.

...

Mutable classes that define a clone() method must be declared final.

Compliant Solution (

...

Unmodifiable Date

...

Wrapper)

If cloning or copying a mutable object is infeasible or expensive, one alternative is to create an unmodifiable view class. This class overrides mutable methods to throw an exception, protecting the mutable class.

...

OBJ04-EX0: Sensitive classes should not be cloneable, per rule " OBJ07-J. Sensitive classes must not let themselves be copied."

Risk Assessment

Creating a mutable class without providing copy functionality can result in the data of its instance becoming corrupted when the instance is passed to untrusted code.

...

Sound automated detection appears to be is infeasible in the general case. Heuristic approaches could be useful.

Related Guidelines

...

...