Immutability offers several benefits, such as thread-safety and prevention of inadvertent modification of fields and malicious tampering. Class invariants and state of immutable objects are always consistent with their requirements, so defensive copying while accepting input or returning values is unnecessary. However, it is sometimes impossible to make sensitive classes immutable. Fortunately, a mechanism exists that allows code to expose mutable classes to untrusted code by granting read-only access, which is achieved largely through unmodifiable wrappers. For example, the Collection
classes include a set of wrappers that allow clients to observe an unmodifiable view of a Collection
object.
Noncompliant Code Example
This noncompliant code example consists of class Mutable
, which allows the internal array object to be modified:
...
An untrusted invoker may call the mutator method setArray()
and violate the object's immutability property. Invoking the getter method getArray()
also allows modification of the private internal state of the class. This class also violates OBJ05-J. Defensively copy private mutable class members before returning their references.
Noncompliant Code Example
This noncompliant code example subclasses the Mutable
class with a MutableProtector
subclass:
...
In this class, invoking the getter method getArray()
does not allow modification of the private internal state of the class, in accordance with OBJ05-J. Defensively copy private mutable class members before returning their references. However, an untrusted invoker may call the method setArray()
and modify the Mutable
object.
Compliant Solution
In general, sensitive classes can be transformed into safe-view objects by providing appropriate wrappers for all methods defined by the core interface, including the mutator methods. The wrappers for the mutator methods must throw an UnsupportedOperationException
so that clients cannot perform operations that affect the immutability property of the object.
...
The MutableProtector
wrapper class overrides the getArray()
method and clones the array. Although calling code gets a copy of the mutable object's array, the original array remains unchanged and inaccessible. The overriding setArray()
method throws an exception if the caller attempts to use this method on the returned object. This object can be passed to untrusted code when read-access to the data is permissible.
Applicability
Failure to provide an unmodifiable, safe view of a sensitive mutable object to untrusted code can lead to malicious tampering and corruption of the object.
Bibliography
...