Callers can trivially access and modify public non-final static fields. Neither accesses nor modifications can be checked by a SecurityManagersecurity manager, and newly set values cannot be validated. Furthermore, multiple threads can modify non-final public static data in ways that are not consistent.

Improper use of {{public static}} fields can also leadresult toin type safety issues. For example, untrusted code mightmay supply an unexpected subtype when the variable is defined to be of a more general type such as {{java.lang.Object}}. \[[Gong 03|AA. Java References#Gong 03]\]

Noncompliant Code Example

This isnoncompliant ancode example is adopted from the JDK 1v1.4.2 software \[[FunctionFT Table|#ref308|AA. Java References#FT 08]\]. 

package org.apache.xpath.compiler;

public class FunctionTable {
    public static FuncLoader m_functions;
}

An attacker can replace the function table as follows:.

FunctionTable.m_functions = <new_table>;

Replacing the function table gives the attacker access to the XPathContext used to evaluate XPath expressions. The XPathContext is used to set the reference node for evaluating XPath expressions. Manipulating this can cause unexpected behavior and XML fields can be modified in inconsistent ways. Also, static variables are global across the Java Runtime Environment (JRE). They can be used as a covert communication channel between different application domains (e.g., through code loaded by different class loaders).

Compliant Solution

Treat public static fields as constants and declare them as final. Consider the use of enum types in the following example.

public class MyClass {
    public static final int LEFT  = 1;
    public static final int RIGHT = 2;
}

The FuncLoader static instance described in the noncompliant example could have been must be declared as final as shown below.

...
public static final FuncLoader m_functions;
...

...

Additionally, for mutable static state one can define variables assessor methods can be defined and add appropriate security checks added. Note that this is a different example, wherein the scope of the static variable has been changed to private.

public class MyClass {

  private static byte[] data;
  
  public static byte[] getData() {
    return data.clone();
  }

  public static void setData(byte[] b) {
    securityCheck();
    data = b.clone();
  }
}

As a cautionary note however, simply changing the modifier to final may not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization. See MSC00-J. Eliminate class initialization cycles and OBJ03-J. Be careful about final reference for more on this problem.

...

Unauthorized modifications to of public static variables can result in unexpected behavior and can bypass important security checks and/or invoke malicious codeviolation of the various class invariants.

...