| Critical Question | Explanation | Potential Vulnerabilities against Security Characteristics in the McCumber Cube Model: Confidentiality, Integrity, Availability |
| Q.1. Limit the accessibility of classes, interfaces, methods, and fields | Use an access modifier to limit their accessibility. The four access levels are: ・ Default: visible to the package. No modifiers are needed. ・ Private: visible to the class only ・ Public: visible to the world ・ Protected: visible to the package and all subclasses. | If wrongly declared, data confidentiality, integrity, and availability may be violated. |
| Q.2. Use a try-with-resources statement to safely handle closeable resources. | The try-with-resources statement ensures that each resource is closed at the end of the statement. | When resources are not closed properly, data confidentiality, integrity, and availability may be violated. |
| Q.3. Avoid using try-catch-finally block. | Ordinary try-catch-finally block can raise some issues: such as failing to close a resource because an exception is thrown as a result of closing another resource, or masking an important exception when a resource is closed. | When resources are not closed properly, data confidentiality, integrity, and availability may be violated. |
| Q.4. Use the same type for the second and third operands in conditional expressions. | Use different types in a conditional expression may cause unintended type conversions. | When types are not the same, data integrity may be violated. |
| Q.5. Avoid using static field variables. | Static variables are class variables, not instance variables. Science any other class in the same scope can access the static variables, it is very difficult to secure them. | Since static variables can be modified by other classes in the same scope, data integrity may be violated. |
| Q.6. If possible make public static fields final | Otherwise, attacker may change the value. | If value changed, data integrity may be violated. |
| Q.7. If possible, use immutable objects. | Contents of the mutable object can be changed. | If contents changed, data integrity may be violated. |
| Q.8. Avoid storing user-given mutable objects directly. | Contents of the mutable objects can be changed. Clone the objects before processing them internally. | If contents changed, data integrity may be violated. |
| Q.9. Avoid using inner classes. | After compilation, any class in the package can access the inner class. Meanwhile, private filed of the inner class will be converted into non-private to permit access by the inner class. | If other classes in the package can access the inner class, data confidentiality and integrity may be violated. If private filed of the inner class changed, data integrity may be violated. |
| Q.10. Avoid using the clone() method to copy untrusted method parameters | Inappropriate use of the clone() method can allow an attacker to exploit vulnerabilities by providing arguments that appear normal but subsequently return unexpected values. Such objects may consequently bypass validation and security checks [22] . | Data confidentiality and integrity may be violated. |
| Q.11. Make secure classes un-cloneable. | Otherwise, malicious developers can instantiate a class without running its constructors [2] . | This may violate data confidentiality and integrity. |
| Q.12. Avoid embedding sensitive information | Malicious developers can obtain such a sensitive information | This may violate data confidentiality. |
| Q. 13. Prevent constructors from calling methods that can be overridden | Constructors that call override methods give attackers a reference to the object being constructed before the object has even been fully initialized | This may violate data integrity |