A non-empty array is always mutable, so 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 array makes no sense; clients will be able object allows clients to modify the contents of the array object (although they will not be able to change the array 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.
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
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.
Code Block | ||
---|---|---|
| ||
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 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 clientany 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 An alternative approach is to have a private array from which a public immutable list is contructedconstructed:
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. 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 , as 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
...
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.OBJ13.RMO | Avoid referencing mutable fields | ||||||
SonarQube |
| ||||||||
SpotBugs |
| MS_EXPOSE_REP | Implemented (since 4.3.0) |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
References
...
[ |
...
...
2008] | Item 13, "Minimize the Accessibility of Classes and Members" |
[JLS 2015] | §6.6, "Access Control" |
...
|AA. Bibliography#Bloch 08]\] Item 13: Minimize the accessibility of classes and membersSEC36-J. Ensure that the bytecode verifier is applied to all involved code upon any modification 02. Platform Security (SEC) 03. Declarations and Initialization (DCL)