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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
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 | ||
|---|---|---|
| ||
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)