Security risk with Externalizable and its inapplicability

Security risk with Externalizable? When can't you use Externalizable?

Potential Security Risk with Externalizable interface

The methods of the Externalizable interface: writeExternal(ObjectOutput) and readExternal(ObjectInput) are public (as is the case with methods of any other interface in Java) and hence there is a security risk that the client may be able to read/write information from/to the object without using the object's own public methods (or fields). Hence, the implementing class must analyze if the object contains any sensitive data or not and it should obviously implement this interface only if it determines that the data contained by the object will not pose any security risk when exposed using the methods of this interface.

When can't we use Externalizable interface?

One of the mandatory requirements of implementing the Externalizable interface is that the implementing class must have a no-arg constructor.

Hence, Externalizable interface can't be implemented by Inner Classes in Java as all the constructors of an inner class in Java will always accept the instance of the enclosing class as a prepended parameter and therefore we can't have a no-arg constructor for an inner class.

Okay... so what should be done in this case? Since we can't use the Externalizable mechanism for inner classes, so the only option left to achieve object serialization is by implementing the Serializable interface. But, this approach also has its own limitations.

Problems with Serialization of Inner Classes

Inner classes (declared in a non-static context) will always contain implicit references to their enclosing classes and these references are always non-transient. So, while object serialization process of inner classes, the enclosing classes will also be serialized. Now the problem is that the synthetic fields generated by Java compilers to implement inner classes are pretty much implementation dependent and hence we may face compatibility issues while deserialization on a different platform having a .class file generated by a different Java compiler. The default serialVerionUID (used to ensure compatibility... read more about this here) may also be different in such cases. Not only this, the names assigned to the local and anonymous inner classes are also implementation dependent. Thus, we see that object serialization of inner classes may pose some unavoidable compatibility issues and hence the serialization of inner classes is strongly discouraged.

Note: One of our visitors, Manish asked this question 'When can't we use Externalizable interface?' in response to the post on Externalizable interface in Java. Thanks Manish for your contribution and I hope the middle part of the above discussion helps you getting the answer to your question. Keep visiting/posting!