SEC01-J. Minimize accessibility of classes and their members

Classes and class members (classes, interfaces, fields and methods) are subject to access control in Java. The access is indicated by an access modifier: public, protected, private, or the absence of an access modifier (the default access; sometimes also called package-private access).

A simplified view of the access control rules is presented in the following table. An 'x' denotes that the particular access is permitted from within that domain. For example, an x under the heading class means that the member is accessible to code present within the same class it is declared in. Likewise, the heading package denotes that the member is accessible from any class (or subclass) defined in the same package, provided that at runtime, the class (or subclass) is loaded by the same class loader as that of the class containing the member. The same class loader condition only applies to package-private member access.

* Sub-classes within the same package can also access members that have no access specifiers (default or package-private visibility). An additional requirement for this is that, at runtime, the subclasses must be loaded by the same class loader as that of the class containing the package-private members. Sub-classes in a different package cannot access such package-private members.

** For referencing protected members, the accessing class can be a sub-class in either the same or a different package.

Classes and class members should be given minimum possible access so that malicious code has the least chance of compromising their security. As far as possible, sensitive classes should avoid implementing interfaces. This is because only public methods are allowed to be declared within interfaces and these carry forward to the public Application Programming Interface (API) of the class. An exception is implementing an unmodifiable interface that exposes a public immutable view of a mutable object (SEC14-J. Provide sensitive mutable classes with unmodifiable wrappers). Additionally, be aware that even if a class's visibility is default, it can be susceptible to misuse if it exposes a public method.

Noncompliant Code Example

In this noncompliant example, the class PublicClass is declared public. The member method getPoint as well as the (x, y) coordinates are also declared public. This gives world-access to the class members.

public class PublicClass {
  public int x;
  public int y;
	
  public void getPoint() {
     System.out.println("(" + x + "," + y + ")");  
  }	
}

Note that a non-public class is also vulnerable if its members are declared public (a violation of OBJ00-J. Declare data members as private and provide accessible wrapper methods).

Compliant Solution

Limiting the scope of classes, interfaces, methods and fields as far as possible reduces the chance of malicious manipulation. Limit the accessibility depending on the desired implementation scope. For non-final classes, reducing the accessibility of methods also eliminates the threat of malicious overriding. This compliant solution demonstrates the most restrictive accessibility.

final class PrivateClass {
  private int x;
  private int y;
	
  private void getPoint() { 
     System.out.println("(" + x + "," + y + ")");  
  }	
}

A top level class such as this one, cannot be declared as private. Package-private accessibility is admissible in this case. However, nested classes may be declared as private.

Compliant Solution

At runtime, any protected or package-private members can be called directly by a class that is maliciously inserted into the same package (package insertion attack). However, this attack is difficult to carry out in practice because in addition to the aforementioned requirement, both the target as well as the untrusted classes must be loaded by the same class loader. Untrusted code is typically deprived of such levels of access.

This compliant solution declares the getPoint() method with package-private accessibility and relaxes the requirements of the previous compliant solution. This allows classes within the same package, loaded by a common class loader, to access the method.

final class PrivateClass {
  private int x;
  private int y;
	
  void getPoint() { 
    System.out.println("(" + x + "," + y + ")");  
  }	
}

Exceptions

EX1: If a class, interface, method or field is part of a published Application Programming Interface (API), it may be declared public. If not, they should be declared either package-private, protected or private for compliance with this guideline.

Risk Assessment

Granting unnecessary access breaks encapsulation and weakens the security of Java applications.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[JLS 05]] Section 6.6, Access Control
[[SCG 07]] Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fields
[[Campione 96]] Access Control
[[McGraw 00]] Chapter 3, Java Language Security Constructs
[[Bloch 08]] Item 13: Minimize the accessibility of classes and members

SEC00-J. Follow the principle of least privilege      02. Platform Security (SEC)      SEC02-J. Guard doPrivileged blocks against untrusted invocations