Do not expose references to mutable objects to client code. Never initialize such a field to a client-provided object reference or return the object reference from an accessor. Exposing a public static final object allows clients to modify the contents of the object (although they will not be able to change the object itself, as it is final).

This rule does not address private mutable objects, see rule OBJ05-J. Do not return references to private mutable class members for more information.

Noncompliant Code Example

Suppose that SomeType is immutable.

public static final SomeType [] SOMETHINGS = { ... };

Even though SomeType is immutable, this declaration allows the SOMETHINGS array to be modified by untrusted clients of the code. Any element of the array can be assigned a new value, namely a reference to a new SomeType object.

This noncompliant code example also violates OBJ01-J. Limit accessibility of fields.

Noncompliant Code Example (getter method)

This noncompliant code example complies with OBJ01-J. Limit accessibility of fields by declaring the array private. But, in declaring the array private, this code example violates OBJ05-J. Do not return references to private mutable class members.

Suppose that SomeType is immutable.

private static final SomeType [] SOMETHINGS = { ... };
public static final getSomethings() {return SOMETHINGS;} 

Even though SomeType is immutable, the public getter method enables untrusted clients to modify the SOMETHINGS array. Any element of the array can be assigned a new value, namely a reference to a new SomeType object.

Compliant Solution (clone)

Continuing with the assumption that SomeType is immutable, one approach is to have a private array and a public method that returns a copy of the array:

private static final SomeType [] SOMETHINGS = { ... };
public static final SomeType [] somethings() {
  return SOMETHINGS.clone();
}

Now, the original array cannot be modified by any client.  If SomeType were mutable, this approach would not be effective because the array clone references the same SomeType objects as the SOMETHINGS array. If the client modified the clone SomeType objects directly, the SomeType objects referenced by the SOMETHINGS array would also change.

Compliant Solution (Unmodifiable List)

Continuing with the assumption that SomeType is immutable, an alternative approach is to have a private array from which a public immutable list is constructed:

private static final SomeType [] THE_THINGS = { ... };
public static final List<SomeType> SOMETHINGS =
  Collections.unmodifiableList(Arrays.asList(THE_THINGS));

Now, neither the original array values nor the public list can be modified by a client. If SomeType were mutable, this would not be effective because the list references the same SomeType objects as the SOMETHINGS array. The unmodifiabileList prevents the list from being modified, not the elements in the list. If the client modified the list's SomeType objects directly, the SomeType objects referenced by the SOMETHINGS array would also change.

Risk Assessment

Having a public static final array is a potential security risk because the array elements may be modified by a client.

Automated Detection

Tool	Version	Checker	Description
Parasoft Jtest		CERT.OBJ13.RMO	Avoid referencing mutable fields
SonarQube		S2386 S2384	Mutable fields should not be "public static" Mutable members should not be stored or returned directly
SpotBugs		MS_EXPOSE_REP EI_EXPOSE_REP EI_EXPOSE_STATIC_REP2 EI_EXPOSE_STATIC_REP2	Implemented (since 4.3.0)

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

References