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).

...

Classes and class members should be given 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|BB. Definitions#sensitive code] through interfaces; interfaces allow only publicly accessible methods, and such methods are part of the public Application Programming Interface (API) of the class. (Note. that Thisthis 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, maycan also be exposed through interfaces.

Protected accessibility is illegal for top-level classes; nested classes may be declared protected. Fields of non-final public classes should rarely be declared protected; untrusted code in another package may can subclass the class and access the member. Furthermore, protected members are part of the API of the class and, thus, require continued support. 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. 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.

...

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

Wiki MarkupA top level class, such as {{Point}}, cannot be declared private. Package-private accessibility is admissible , provided package insertion attacks are avoided (see \[[. (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 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.

...

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.

...

For any given body of code, we can compute the minimum accessibility for each class and member such so that we do not introduce no new compilation errors. The limitation of this is that this may could 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 could be unused because the particular body of code examined coincidentally lacks references to the members.

...

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

Related Guidelines

SCG 2007 Guideline 1-1. Limit the accessibility of classes, interfaces, methods, and fields

Bibliography

\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 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
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fields

...

SEC00-J. Avoid granting excess privileges      02. Platform Security (SEC)      SEC02-J. Guard doPrivileged blocks against untrusted invocation and leakage of sensitive data