Skip to end of metadata
Go to start of metadata

Serialization and deserialization features can be exploited to bypass security manager checks. A serializable class may contain security manager checks in its constructors for various reasons, including preventing untrusted code from modifying the internal state of the class. Such security manager checks must be replicated wherever a class instance can be constructed. For example, if a class enables a caller to retrieve sensitive internal state contingent upon security checks, those checks must be replicated during deserialization to ensure that an attacker cannot extract sensitive information by deserializing the object.

Noncompliant Code Example

In this noncompliant code example, security manager checks are used within the constructor but are omitted from the writeObject() and readObject() methods that are used in the serialization-deserialization process. This omission allows untrusted code to maliciously create instances of the class.

(Although there are security manager checks, the data in this example is not sensitive. Serializing unencrypted sensitive data violates SER03-J. Do not serialize unencrypted sensitive data.)

AccessDeniedException and InvalidInputException are both security exceptions that can be thrown by any method without requiring a throws declaration.

Compliant Solution

This compliant solution implements the required security manager checks in all constructors and methods that can either modify or retrieve internal state. Consequently, an attacker cannot create a modified instance of the object (using deserialization) or read the serialized byte stream to reveal serialized data.

Refer to SEC04-J. Protect sensitive operations with security manager checks for information about implementing the performSecurityManagerCheck() method, which is important for protection against finalizer attacks.

The ObjectInputStream.defaultReadObject() fills the object's fields with data from the input stream. Because each field is deserialized recursively, it is possible for the this reference to escape from control of the deserialization routines. This can happen if a referenced object publishes the this reference in its constructors or field initializers (see TSM01-J. Do not let the this reference escape during object construction for more information). To be compliant, recursively deserialized subobjects must not publish the this object reference.

Risk Assessment

Allowing serialization or deserialization to bypass the security manager may result in classes being constructed without required security checks.




Remediation Cost









Automated Detection

Parasoft Jtest9.5SECURITY.WSC.SCSERImplemented

Related Guidelines

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 8-4 / SERIAL-4: Duplicate the SecurityManager checks enforced in a class during serialization and deserialization

Android Implementation Details

The java.security package exists on Android for compatibility purposes only, and it should not be used.


[Long 2005]

Section 2.4, "Serialization"



  1. As in FIO00-J, it turns out that validating after defaultReadObject doesn't actually work. Avoid making sensitive classes directly serialisable.

  2. Marked review2, but not happy with this rule. Complying with SER03-J requires that we not serialize sensitive data, so credit cards are out. This rule's text seems to have overlap with SER03-J; hopefully I've taken it all out.

    • We assume that AccessDeniedException and InvalidInputException are both security exceptions, and, for that reason, are not checked. So any method can throw them without requiring a throws declaration.

    But I see them in code as checked exceptions because of all the throws clauses.

    • I think everything after and including

      This allows untrusted code to maliciously create instances

      can occur below the pink block.
    1. There are throws clauses only on the methods that throw the exceptions directly. But I moved the text that you suggested.

  3. Automated Detection?