Page History

Classes and class members (classes, interfaces, fields and methods) are subject to access control controlled 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 The table below presents a simplified view of the access control rules is presented in the following table. An 'x' denotes indicates that the particular access is permitted from within that domain. For example, an 'x under ' in the heading class column means that the member is accessible to code present within the same class in which it is declared in. Similarly, the heading package denotes column indicates 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 loaded the class containing the member. The same class loader condition applies only applies to package-private member access.

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

** For referencing protected membersTo reference a protected member, the accessing class can be a sub-class code must be contained in either the same or a different packagethe 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.

Classes and class members should be given minimum possible access so that malicious code has the least opportunity to compromise their security. As far as possible, _sensitive_ classes should avoid exposing internal functionality methods that contain (or invoke) [sensitive code|BB. Definitions#sensitive code] through interfaces; because interfaces allow only {{public}}publicly accessible methods, and such methods carryare forwardpart toof the public Application Programming Interface (API) of the class. (Note.  This is exactly the opposite of Bloch's recommendation to prefer interfaces for APIs \[[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 guideline [SEC14-J. Provide sensitive mutable classes with unmodifiable wrappers].) Additionally, note that even if a non-final 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 may also be exposed through interfaces.

Protected The protected accessibility is illegal for defining top-level classes, though ; nested classes can may be declared protected. Fields of non-final public classes should rarely be declared protected because ; untrusted code in another package may subclass the class if it is public and non-final and access the member. Furthermore, protected members are part of the Application Programming Interface ( API ) of the class and thus require continued support. If When this guideline is followed, there is no need to declare a field as protected. The guideline OBJ00-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 point, it may be declared public. If not, it 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.

...

In this noncompliant code example, the class Point is declared public. Consequently. Even though this example complies with guideline OBJ00-J. Declare data members as private and provide accessible wrapper methods, untrusted code may 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 + ")");  
  }	
}

This example complies with guideline OBJ00-J. Declare data members as private and provide accessible wrapper methods.

Compliant Solution (Final Classes With Public Methods)

...

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 provided package insertion attacks

 are avoided (see \[[ENV01-J. Place all privileged code in a single package and seal the package]\]). 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 guideline cannot override the method and expose it to untrusted code, so its accessibility is irrelevant). For non-final classes, reducing the accessibility of methods to private or package-private eliminates this threat.

A nested class may be declared private even though the compiler changes its accessibility to package-private.

Compliant Solution (Non-Final Classes With Non-Public Methods)

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

...

This noncompliant code example shows a public Point class that attempts to implement instance control using a private constructor. However, untrusted code may invoke the public static getPoint() method without instantiating the class because the class 's accessibility is public.

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 + ")");  
  } 
}

...

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 so 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 + ")");  
  } 
}

...

For any given body of code, we can compute the minimum accessibility for each class and member such that we introduce no new compilation errors. The limitation of this is that this may not bear any resemblance to what the designer intended when they wrote it. For example, unused members can obviously be marked private. However, such members may be unused because the particular body of code examined happens not to have used themcoincidentally lacks references to the members.

Related Vulnerabilities

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

Bibliography

\[[JLSBloch 20052008|AA. Bibliography#JLSBibliography#Bloch 0508]\] [Section 6.6, Access Control|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6]
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fieldsItem 13: Minimize the accessibility of classes and members; Item 16: Prefer interfaces to abstract classes
\[[Campione 1996|AA. Bibliography#Campione 96]\] [Access Control|http://www.telecom.ntua.gr/HTML.Tutorials/java/javaOO/accesscontrol.html]
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Section 6.6, Access Control|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6]
\[[McGraw 2000|AA. Bibliography#McGraw 00]\] Chapter 3, Java Language Security Constructs
\[[BlochSCG 20082007|AA. Bibliography#BlochBibliography#SCG 0807]\] Item 13: MinimizeGuideline 1-1 Limit the accessibility of classes and members
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 16: Prefer, interfaces, tomethods, abstractand classesfields

...

SEC00-J. Avoid granting excess privileges      02. Platform Security (SEC)      SEC02-J. Guard doPrivileged blocks against untrusted invocations