Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A non-empty array is always mutable, so a public static final array makes no sense; clients will be able to modify the contents of the array (although they will not be able to change the array itself, as it is final).

Noncompliant Code Example

Code Block
bgColor#FFCCCC
public static final SomeType [] SOMETHINGS = { ... };

Wiki Markup
With this declaration, {{SOMETHINGS\[1\]}}, etc. can be modified by clients of the code.

Compliant Solution

One approach is to have a private array and a public method that returns a copy of the array:

Code Block
bgColor#ccccff
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 contructed:

Code Block
bgColor#ccccff
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, as the array elements may be modified by a client.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

SEC37-J

medium

likely

low

P18

L1

Automated Detection

TODO

Related Vulnerabilities

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

References

Wiki Markup
\[[JLS 06|AA. Java References#JLS 06]\] Section 6.6, Access Control
\[[Bloch 08|AA. Java References#Bloch 08]\] Item 13: Minimize the accessibility of classes and members


SEC36-J. Ensure that the bytecode verifier is applied to all involved code upon any modification      00. Security (SEC)      01. Declarations and Initialization (DCL)