Page History

...

This permits a malicious subclass to offer wider access to the restricted method than was originally intended.

Noncompliant Code Example

This noncompliant code example exemplifies how a malicious subclass Sub can override the doLogic() method of the superclass. Any user of Sub will be able to invoke the doLogic method as the base class BadScope defines it with the protected access modifier. The class Sub can allow more access than BadScope by declaring its own version of the doLogic() method {{public}.

class BadScope {
  protected void doLogic() { 
    System.out.println("Super invoked"); 
  }
}

public class Sub extends BadScope {
  public void doLogic() { 
    System.out.println("Sub invoked");
    // Do sensitive operations
  }
}

Compliant Solution

Override methods only when necessary. Declare methods and fields final whenever possible to avoid malicious subclassing. When methods and fields cannot be declared final, refrain from increasing the accessibility of overridden methods. (See guideline SEC01-J. Minimize the accessibility of classes and their members.)

class BadScope {
  protected final void doLogic() { // declare as final 
    System.out.println("Super invoked");
    // Do sensitive operations
  }
}

Noncompliant Code Example

This noncompliant code example overrides the finalize() method of the superclass Base, changing its accessibility from protected to public.

...

final class SubClass extends Base {
  public void finalize() {
    // ...
  }
}

Compliant Solution

This compliant solution correctly declares the finalize() method protected. It is not possible to further limit the accessibility as Object's finalize method itself is declared protected.

...

It is recommended but not mandatory to limit the accessibility of a subclass's constructor to that of the superclass's constructor.

Exceptions

SPC01-EX1: According to Sun's Secure Coding Guidelines [[SCG 2007]]

One noteworthy exception to this guideline pertains to classes that implement the java.lang.Cloneable interface. In these cases, the accessibility of the Object.clone method should be increased from protected to public.

Risk Assessment

Subclassing allows weakening of access restrictions, which can compromise the security of a Java application.

Automated Detection

Straightforward.

Related Vulnerabilities

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

Related Guidelines

MITRE CWE: CWE-487 "Reliance on Package-level Scope"

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

Bibliography

\[[JLS 2005|AA. Bibliography#JLS 05]\] [Section 8.4.8.3|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.3], "Requirements in Overriding and Hiding"

...