FindBugs raises a bug called EI_EXPOSE_REP with the following description :
EI: May expose internal representation by returning reference to mutable object
Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.
Several questions on SO (1, 2 and 3) have already addressed how to avoid such bug and I understand that it is a development best practice to prevent modifications of immutable objects however it is not clear to me why such bug belongs to the MALICIOUS_CODE category.
What is the real threat behind this ?
If it's a malicious code problem, the attacker can do almost anything he wants and mutability wouldn't be the biggest problem. If it is a vulnerability, it can be exploited only if untrusted code is executed also and I can't see any usecase where this is true.
Any perspective on this ?
Thanks !
The point is that any time you open up an implementation you run the risk of code doing damage, intentionally or otherwise. Obviously a malicious library user, for example, could just disassemble your jar and learn details that way–the point is to minimize the risk of exposure: it cannot be eliminated.
A trivial example of external code accessing your library:
Consider something simple like an object that holds an access level. If it was mutable, it's conceivable a library user could set their own access level. Something this trivial would rarely be exposed by any reasonable library, but it's a clear example of when an internal representation might be abused.
The bottom line is that exposed mutable state makes code difficult to reason about, and difficult to protect. Your code or others may accidentally, or deliberately, modify something your own code/library uses. If your library then changes its behavior without taking that into account, you may introduce a subtle (or not so subtle) bug.
The ability to have an object to hide state and provide a strong, static interface is core to Java mobile code security. There are a number of ways that a programmer messing this up can cause a vulnerability.
For value objects, consider String. We trust any instance of String not to change. We don't want to validate [check] a particular file name, for example, we don't want it to change when we actually use it (note, java.io.File doesn't work well in this sense). Also a mutable internals may have malicious equals method (say), that is called by the enclosing class' equals, but maliciously acquires references to internal objects of other enclosing class instances compared to.
Reference types are often object capabilities. Typically they will attenuate a capability of an object they were endowed with (passed through the constructor). Say, you can only write a file to a particular directory through the instance you have access to, but it has a field with a capability to write to an entire filesystem.
Then there's the Java 2 Security Model, and that's never a good thing. The inner object may have methods called in a privileged context, which isn't usually a problem. Now a malicious party places in object (of a trusted type) that does something that it shouldn't in that context.
Of course, watch out for randomly subclassing classes. They may acquire a get method in future versions.
Having said that, in my opinion this warning from Findbugs is not helpful. The code probably wasn't intented to hide the object.
(For a verbose description of the problem of exposing internal objects see Chapter 13 (and 14) of Michael Feathers Working Effectively with Legacy Code.)
来源：https://stackoverflow.com/questions/14124683/findbugs-real-threat-behind-ei-expose-rep