...
This also means that there is potential for some functionality having a restrictive modifier to be overridden by a less restrictive modifier.
...
Noncompliant Code Example
This non-compliant noncompliant code example exemplifies how a malicious subclass Sub
can override the doLogic
method of the super class. Any user of Sub
will be able to invoke the doLogic
method even though the base class BadScope
defined it with the private
access modifier.
Code Block | ||
---|---|---|
| ||
class BadScope { private void doLogic() {System.out.println("Super invoked");} } public class Sub extends BadScope { public void doLogic() {System.out.println("Sub invoked"); //do restrictive operations } } |
Compliant Solution
Do not override a method unless absolutely necessary. Declare all methods and fields final
to avoid malicious subclassing. This is in compliance with <xyz rule>
Code Block | ||
---|---|---|
| ||
class BadScope { private final void doLogic() {System.out.println("Super invoked");} } |
Risk Assessment
TODO
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SCP01-J | ?? | ?? | ?? | P?? | L?? |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
JLS 8.4.8.3 Requirements in Overriding and Hiding