Skip to end of metadata
Go to start of metadata

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

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

With this declaration, SOMETHINGS[1], etc. can be modified by clients of the code.

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

Compliant Solution

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 values cannot be modified by a client.

Compliant Solution 2

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.

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

OBJ13-J

Medium

Likely

Low

P18

L1

Automated Detection

Related Vulnerabilities

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

References

[Bloch 2008]Item 13, "Minimize the Accessibility of Classes and Members"
[JLS 2015]§6.6, "Access Control"




9 Comments

  1. Ahh, once again a Java programmer laments the absence of the 'const' keyword (smile)

    This rule suffers from a hidden assumption. I think it is trying to say final != const, assuming that programmers would assume the opposite. I'll admit to being out of touch with the Java communitity as of late, but I thought any programmar who knew of the 'final' keword knew it does not promise immutability.

    Furthermore the final!=const problem is not limited to Java arrays, but pertains to any public field member that is also an object (and not a primiitve type like int). If class A has a public (or protected) object b of class B, then if you can access object b, you can modify it, even if A is final. This is a well-known issue of the 'final' keyword.

  2. Am I wrong in thinking that this is a specialization of OBJ01-J. Limit accessibility of fields?

    1. To answer my own question: there's overlap, but this is broader in that it includes what's returned from methods as well.

  3. Please update risk assessment to reflect OBJ13-J

  4. As I read this rules, the begining seems to refer to OBJ05-J  OBJ05-J. Do not return references to private mutable class members

    "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."

    Next, explanation and samples is more about static fields.

     

    So, i would put the firsts two setences into OBJ05-J. Do not return references to private mutable class members and delete them here.

     

    1. The two rules are similar but distinct. I've added sentences to the intros of both rules, so they cross-reference each other and explain why they are distinct.

      1. OK, Thanks !
        That feels good (smile)