Page History

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

The following table below presents a simplified view of the access control rules. An 'x' indicates that the particular access is permitted from within that domain. For example, an 'x' in the class column means that the member is accessible to code present within the same class in which it is declared. Similarly, the package column indicates that the member is accessible from any class (or subclass) defined in the same package, provided that the class (or subclass) is loaded by the class loader that loaded the class containing the member. The same class loader condition applies only to package-private member access.

* Subclasses within the same package can also access members that have no lack access specifiers (default or package-private visibility). An additional requirement for access is that the subclasses must be loaded by the class loader that loaded the class containing the package-private members. Subclasses in a different package cannot access such package-private members.

** To reference a protected member, the accessing code must be contained either in either the class that defines the protected member or in a subclass of that defining class. Subclass access is permitted without regard to the package location of the subclass.

Wiki MarkupClasses and class members must be given the minimum possible access so that malicious code has the least opportunity to compromise security. As far as possible, classes should avoid exposing methods that contain (or invoke) [sensitive code|java:BB. Glossary#sensitive code] through interfaces; interfaces allow only publicly accessible methods, and such methods are part of the public Application Programming Interface public application programming interface (API) of the class. (Note that this is the opposite of Joshua Bloch's recommendation to prefer interfaces for APIs \[java: [Bloch 2008|AA. Bibliography#Bloch 08], Item 16\].) One exception to this is implementing an _unmodifiable_ interface that exposes a public immutable view of a mutable object. (See rule [java:OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code].) Additionally, note that even if a non-final Note that even if a nonfinal class's visibility is default, it can be susceptible to misuse if it contains public methods. Methods that perform all necessary security checks, as well as sanitizing all inputs, can also be exposed through checks and sanitize all inputs may be exposed through interfaces.

Protected accessibility is invalid for topnon-level nested classes; , but nested classes may be declared protected. Fields of non-final nonfinal public classes should rarely be declared protected; untrusted code in another package can subclass the class and access the member. Furthermore, protected members are part of the API of the class and , consequently , require continued support. When this rule is followed, there is no need to declare a field as protected. The rule OBJ01-J. Declare data members as private and provide accessible wrapper methods recommends declaring fields as private.

If a class, interface, method, or field is part of a published API, such as a web service end pointendpoint, it may be declared public. Other classes and members should be declared either package-private or private. For example, non-security-critical classes are encouraged to provide public static factories to implement instance control with a private constructor.

Noncompliant Code Example (Public Class)

This noncompliant code example concerns defines a class that is internal to a system , and not part of any public API. Nonetheless, the this class Point is declared public. Even though this example complies with rule OBJ01-J. Declare data members as private and provide accessible wrapper methods, untrusted code could instantiate Point and invoke the public getPoint() to obtain the coordinates.  

public final class Point {
  private final int x;
  private final int y;

  public Point(int x, int y) {
    this.x = x;
    this.y = y; 
  }
	
  public void getPoint() {
    System.out.println("(" + x + "," + y + ")");  
  }	
}

Even though this example complies with OBJ01-J. Declare data members as private and provide accessible wrapper methods, untrusted code could instantiate Point and invoke the public getPoint() method to obtain the coordinates.

Compliant Solution (Final Classes

...

with Public Methods)

This compliant solution declares the Point class as package-private , in accordance with its status as not part of any public API.:

final class Point {
  private final int x;
  private final int y;

  Point(int x, int y) {
    this.x = x;
    this.y = y; 
  }
	
  public void getPoint() { 
    System.out.println("(" + x + "," + y + ")");  
  }	
}

A top-level class, such as Point, cannot be declared private. Package-private accessibility is admissible, acceptable provided package insertion attacks are avoided. (See ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it.) A package insertion attack occurs when, at runtime, any protected or package-private members of a class can be called directly by a class that is maliciously inserted into the same package. However, this attack is difficult to carry out in practice because, in addition to the requirement of infiltrating into the package, the target and the untrusted class must be loaded by the same class loader. Untrusted code is typically deprived of such levels of access.

Because the class is final, the getPoint() method can be declared public. ( A public subclass that violates this rule cannot override the method and expose it to untrusted code, so its accessibility is irrelevant). For non-final nonfinal classes, reducing the accessibility of methods to private or package-private eliminates this threat.

Compliant Solution (

...

Nonfinal Classes with Nonpublic Methods)

This compliant solution declares the Point class and its getPoint() method as package-private. This , which allows the Point class to be non-final nonfinal and allows getPoint() to be invoked by classes present within the same package and loaded by a common class loader.:

class Point {
  private final int x;
  private final int y;

  Point(int x, int y) {
    this.x = x;
    this.y = y; 
  }
	
  void getPoint() { 
    System.out.println("(" + x + "," + y + ")");  
  }	
}

Noncompliant Code Example (Public Class

...

with Public Static Method)

This noncompliant code example again concerns defines a class that is internal to a system , and not part of any public API. Nonetheless, the class Point is declared public. Even though this example complies with rule OBJ01-J. Declare data members as private and provide accessible wrapper methods, untrusted code could instantiate Point and invoke the public getPoint() to obtain the coordinates. This noncompliant

...

public final class Point {
  private static final int x = 1;
  private static final int y = 2;

  private Point(int x, int y) {}
    
  public static void getPoint() { 
    System.out.println("(" + x + "," + y + ")");  
  } 
}

Even though this example complies with OBJ01-J. Declare data members as private and provide accessible wrapper methods, untrusted code could access Point and invoke the public static getPoint() to obtain the default coordinates. The attempt to implement instance control using a private constructor is futile because the public static method exposes internal class contents.

Compliant Solution (Package-Private Class)

This compliant solution reduces the accessibility of the class to package-private. As a consequence, access to the getPoint() method is restricted to classes located within the same package. This prevents untrusted code from invoking getPoint() and obtaining the coordinates.:

final class Point {
  private static final int x = 1;
  private static final int y = 2;

  private Point(int x, int y) {}
    
  public static void getPoint() { 
    System.out.println("(" + x + "," + y + ")");  
  } 
}

Exceptions

Access to the getPoint() method is restricted to classes located within the same package. Untrusted code is prevented from invoking getPoint() and obtaining the coordinates.

Applicability

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

OBJ02-EX0: A system with an API designed to be used for use (and possibly extended) by third-party code , must have classes and methods sufficiently public to provide that APImust expose the API through a public interface. The demands of such an API override this rule.

Risk Assessment

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

Automated Detection

guideline.

For any given body piece of code, we can compute the minimum accessibility for each class and member so that we do not introduce new can be computed so as to avoid introducing compilation errors. The A limitation of this is that this could not bear the result of this computation may lack any resemblance to what the designer programmer intended when they wrote itthe code was written. For example, unused members can obviously be marked declared to be private. However, such members could be unused only because the particular body of code examined coincidentally lacks references to the members. Nevertheless, this computation can provide a useful starting point for a programmer who wishes to minimize the accessibility of classes and their members.

Related Guidelines

Bibliography

Automated Detection

Bibliography

...

Image Added Image Added Image AddedOBJ01-J. Declare data members as private and provide accessible wrapper methods      04. Object Orientation (OBJ)      OBJ03-J. Do not mix generic with nongeneric raw types in new code