Returning references to internal mutable members of a class can compromise an application's security, both by breaking encapsulation and by providing the opportunity to corrupt the internal state of the class (whether accidentally or maliciously). As a result, programs must not return references to internal private mutable classes.
See rule OBJ13-J. Ensure that references to mutable objects are not exposed for details about leaking references to non-private objects.
Noncompliant Code Example
...
Note that making deep copies of the keys of a hash table is unnecessary; shallow copying of the references suffices because a hash table's contract dictates that its keys must produce consistent results to the equals() and hashCode() methods. Mutable objects whose equals() or hashCode() method results may be modified are not suitable keys.
Exceptions
OBJ05-J-EX0: When a method is called with only an immutable view of an object, that method may freely use the immutable view without defensive copying. This decision should be made early in the design of the API. Note that new callers of such methods must also expose only immutable views.
...
Returning references to internal object state (mutable or immutable) can render an application susceptible to information leaks and corruption of its objects' states, which consequently violates class invariants. Control flow can also be affected in some cases.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OBJ05-J | High | Probable | Medium | P12 | L1 |
Automated Detection
Sound automated detection is infeasible; heuristic checks could be useful.
| Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Parasoft Jtest |
| CERT.OBJ05.CPCL CERT.OBJ05.MPT CERT.OBJ05.SMO CERT.OBJ05.MUCOP | Enforce returning a defensive copy in 'clone()' methods Do not pass user-given mutable objects directly to certain types Do not store user-given mutable objects directly into variables Provide mutable classes with copy functionality | ||||||
| SonarQube |
| S2384 | Mutable members should not be stored or returned directly Implemented for Arrays, Collections and Dates. |
Related Vulnerabilities
Pugh [Pugh 2009] cites a vulnerability discovered by the Findbugs static analysis tool in the early betas of JDK 1.7 in which the sun.security.x509.InvalidityDateExtension class returned a Date instance through a public accessor without creating defensive copies.
Related Guidelines
CWE-375, Returning a Mutable Object to an Untrusted Caller |
Bibliography
[API 2014] | Method clone() |
Item 39, "Make Defensive Copies When Needed" | |
Section 3.2, "Publication and Escape: Allowing Internal Mutable State to Escape" | |
Section 9.4, "Private Object State and Object Immutability" | |
| [Pugh 2009] |
...
...