Skip to end of metadata
Go to start of metadata

An object is partially initialized if a constructor has begun building the object but has not finished. As long as the object is not fully initialized, it must be hidden from other classes.

Other classes might access a partially initialized object from concurrently running threads. This rule is a specific instance of TSM01-J. Do not let the this reference escape during object construction but focuses only on single-threaded programs. Multithreaded programs must also comply with TSM03-J. Do not publish partially initialized objects.

Some uses of variables require failure atomicity. This requirement typically arises when a variable constitutes an aggregation of different objects, for example, a composition-and-forwarding-based approach, as described in OBJ02-J. Preserve dependencies in subclasses when changing superclasses. In the absence of failure atomicity, the object can be left in an inconsistent state as a result of partial initialization.

There are three common approaches to dealing with the problem of partially initialized objects:

  • Exception in constructor. This approach throws an exception in the object's constructor. Unfortunately, an attacker can maliciously obtain the instance of such an object. For example, an attack that uses the finalizer construct allows an attacker to invoke arbitrary methods within the class, even if the class methods are protected by a security manager.
  • Final field. Declaring the variable that is initialized to the object as final prevents the object from being partially initialized. The compiler produces a warning when there is a possibility that the variable's object might not be fully initialized. Declaring the variable final also guarantees initialization safety in multithreaded code. According to The Java Language Specification (JLS), §17.5, "final Field Semantics" [JLS 2015], "An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields." In other words, when a constructor executing in one thread initializes a final field to a known safe value, other threads are unable to see the preinitialized values of the object.
  • Initialized flag. This approach allows uninitialized or partially initialized objects to exist in a known failed state; such objects are commonly known as zombie objects. This solution is error prone because any access to such a class must first check whether the object has been correctly initialized.

The following table summarizes these three approaches:


Uninitialized Values

Partially Initialized Objects

Exception in constructor


Does not prevent

Final field



Initialized flag



Noncompliant Code Example (Finalizer Attack)

This noncompliant code example, based on an example by Kabutz [Kabutz 2001], defines the constructor of the BankOperations class so that it performs social security number (SSN) verification using the method performSSNVerification(). The implementation of the performSSNVerification() method assumes that an attacker does not know the correct SSN and trivially returns false.

The constructor throws a SecurityException when SSN verification fails. The UserApp class appropriately catches this exception and displays an "Access Denied" message. However, these precautions fail to prevent a malicious program from invoking methods of the partially initialized class BankOperations, as shown by the following exploit code.

The goal of the attack is to capture a reference to the partially initialized object of the BankOperations class. If a malicious subclass catches the SecurityException thrown by the BankOperations constructor, it is unable to further exploit the vulnerable code because the new object instance has gone out of scope. Instead, an attacker can exploit this code by extending the BankOperations class and overriding the finalize() method. This attack intentionally violates MET12-J. Do not use finalizers.

When the constructor throws an exception, the garbage collector waits to grab the object reference. However, the object cannot be garbage-collected until after the finalizer completes its execution. The attacker's finalizer obtains and stores a reference by using the this keyword. Consequently, the attacker can maliciously invoke any instance method on the base class by using the stolen instance reference. This attack can even bypass a check by a security manager.

Compliance with ERR00-J. Do not suppress or ignore checked exceptions and ERR03-J. Restore prior object state on method failure can help to ensure that fields are appropriately initialized in catch blocks. A developer who explicitly initializes the variable to null is more likely to document this behavior so that other programmers or clients include the appropriate null reference checks where required. Moreover, this approach guarantees initialization safety in a multithreaded scenario.

Compliant Solution (Final)

This compliant solution declares the partially initialized class final so that it cannot be extended:

Compliant Solution (Final finalize())

If the class itself cannot be declared final, it can still thwart the finalizer attack by declaring its own finalize() method and making it final:

This solution is allowed under exception MET12-J-EX1, which permits a class to use an empty final finalizer to prevent a finalizer attack.

Compliant Solution (Java SE 6, Public and Private Constructors)

This compliant solution applies to Java SE 6 and later versions in which the JVM will not execute an object's finalizer if the object's constructor throws an exception before the java.lang.Object constructor exits [SCG 2009]. Developers can use this feature to throw an exception in a constructor without risking the escape of a partially initialized object (via the finalizer attack described previously). However, doing so requires a careful coding of the constructor because Java ensures that the java.lang.Object constructor executes on or before the first statement of any constructor. If the first statement in a constructor is a call to either a superclass's constructor or another constructor in the same class, then the java.lang.Object constructor will be executed somewhere in that call. Otherwise, Java will execute the default constructor of the superclass before any of the constructor's code and the java.lang.Object constructor will be executed through that (implicit) invocation.

Consequently, to execute potentially exception-raising checks before the java.lang.Object constructor exits, the programmer must place them in an argument expression of an explicit constructor invocation. For example, the single constructor can be split into three parts: a public constructor whose interface remains unchanged, a private constructor that takes (at least) one argument and performs the actual work of the original constructor, and a method that performs the checks. The public constructor invokes the private constructor on its first line while invoking the method as an argument expression. All code in the expression will be executed before the private constructor, ensuring that any exceptions will be raised before the java.lang.Object constructor is invoked.

This compliant solution demonstrates the design. Note that the performSSNVerification() method is modified to throw an exception rather than returning false if the security check fails.

Compliant Solution (Initialized Flag)

Rather than throwing an exception, this compliant solution uses an initialized flag to indicate whether an object was successfully constructed. The flag is initialized to false and set to true when the constructor finishes successfully.

The initialized flag prevents any attempt to access the object's methods if the object is not fully constructed. Because each method must check the initialized flag to detect a partially constructed object, this solution imposes a speed penalty on the program. It is also harder to maintain because it is easy for a maintainer to add a method that fails to check the initialized flag.

According to Charlie Lai [Lai 2008]:

If an object is only partially initialized, its internal fields likely contain safe default values such as null. Even in an untrusted environment, such an object is unlikely to be useful to an attacker. If the developer deems the partially initialized object state secure, then the developer doesn't have to pollute the class with the flag. The flag is necessary only when such a state isn't secure or when accessible methods in the class perform sensitive operations without referencing any internal field.

The initialized flag is volatile to ensure that the setting of the flag to true happens-before any reads of the variable. The current code does not allow for multiple threads to read the field before the constructor terminates, but this object could always be subclassed and run in an environment where multiple threads can access the variable.

Noncompliant Code Example (Static Variable)

This noncompliant code example uses a nonfinal static variable. The JLS does not mandate complete initialization and safe publication even though a static initializer has been used. Note that in the event of an exception during initialization, the variable can be incorrectly initialized.

Compliant Solution (Final Static Variable)

This compliant solution guarantees safe publication by declaring the Stock field final:

Unlike the previous compliant solution, however, this approach permits a possibly null value but guarantees that a non-null value refers to a completely initialized object.

Risk Assessment

Allowing access to a partially initialized object can provide an attacker with an opportunity to resurrect the object before or during its finalization; as a result, the attacker can bypass security checks.




Remediation Cost









Automated Detection

Automated detection for this rule is infeasible in the general case. Some instances of nonfinal classes whose constructors can throw exceptions could be straightforward to diagnose.

Parasoft Jtest9.5EXCEPT.ENFCImplemented

Related Vulnerabilities

CVE-2008-5353 describes a collection of vulnerabilities in Java. In one of the vulnerabilities, an applet causes an object to be deserialized using ObjectInputStream.readObject(), but the input is controlled by an attacker. The object actually read is a serializable subclass of ClassLoader, and it has a readObject() method that stashes the object instance into a static variable; consequently, the object survives the serialization. As a result, the applet manages to construct a ClassLoader object by passing the restrictions against this in an applet, and the ClassLoader allows it to construct classes that are not subject to the security restrictions of an applet. This vulnerability is described in depth in SER08-J. Minimize privileges before deserializing from a privileged context.

Related Guidelines

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 4-5 / EXTEND-5: Limit the extensibility of classes and methods
Guideline 7-3 / OBJECT-3: Defend against partially initialized instances of non-final classes


[API 2006]


[Darwin 2004]

Section 9.5, "The Finalize Method"

[Flanagan 2005]

Section 3.3, "Destroying and Finalizing Objects"

[JLS 2015]

§8.3.1, Field Modifiers 
§12.6, Finalization of Class Instances

§17.5, "final Field Semantics"

[Kabutz 2001]

Issue 032, "Exceptional Constructors—Resurrecting the Dead"

[Lai 2008]

"Java Insecurity: Accounting for Subtleties That Can Compromise Code"

[Masson 2011]"Secure Your Code against the Finalizer Vulnerability"



  1. The solution should be to make the class final. Only resort to other hacks if it is not possible to change the API.

    Here initialized should not be static. It should generally be volatile. The idea with the initialized flag solution should be to make sure instances of the class are not usable until they have completed their construction. A flag is one technique, but just making the class unusable if existing fields remain at their initial values is another.

    1. I've removed the "solution" with the initialized flag hack as it didn't solve the problem!

      1. Actually, we could still keep that as an alternative solution in cases where it is not possible to declare the class final (although it is indeed cumbersome to use that hack all the time). Any thoughts?

  2. In the attack code in the noncompliant example, should "Stolen the instance in finalize of " be "Stole the instance in finalize of "?

    1. Both are correct. The method is announcing that it has successfully stolen the instance. You can use past or past perfect tense here because the theft has succeeded.

  3. Hi there..

    I think the word "Zombie" flag mean for a few programmers only. It's better to use common and relevant word such as "initialized" flag or something. Just like the Secure Coding Guideline for Java in oracle website.

    Just an idea..


    1. s/zombie/initialized/g;

  4. In the table:


    Prevents uninitialized values

    Prevents partially-initialized objects

    initialized flag



    Why do we have "no" in both columns even though this is suggested as a CS. I think it should be "yes".

    1. It's a fine distinction. The initiailized flag does not prevent unit'd or partially init'd values, it detects them.

  5. 1.

    The UserApp class appropriately catches this exception and displays an access denied message.

    It seems that the program does not display any access denied message...

    The first BankOperations and the second Storage should be put in the same block, otherwise it look confusing. As I read:

    ...initialized class BankOperations, as shown by the following exploit code.

    the following code is not a exploit code, but a Storage class definition.

    1. It seems that the program does not display any access denied message...

      We meant 'invalid SSN'. I changed the code to say 'access denied' for clarity.

      the following code is not a exploit code, but a Storage class definition.

      I rearranged the code as suggested. The code & text is all the same but in a (hopefully) clearer order.

  6. What is the connection of the related vulnerability to this rule? The vuln. relates to object serialization, subclassing etc. and the rule is about exceptions in constructors? The only commonality seems to be the risks of unfinalized security-critical classes, but that seems to tangential to be worth including this vuln. as related.

  7. Seems like the intro could use some more explanation. The first sentences states that the partially initialized objects are a problem, but the following paragraphs do not expand on this.

  8. Can the second two paragraphs of the intro be moved to the end of the intro? They seem like side notes and interrupt the flow of the text. Moreover, what it is the purpose of the point about "failure atomicity"? Is it trying to say that failure atomicity can address this issue? If so, can we phrase it that way explicitly? If not, what then?

  9. I found a good article on finalizer attack. Added it to Bibliography section (-: