Kingdom: Encapsulation
Encapsulation is about drawing strong boundaries. In a web browser that might mean ensuring that your mobile code cannot be abused by other mobile code. On the server it might mean differentiation between validated data and unvalidated data, between one user's data and another's, or between data users are allowed to see and data that they are not.
J2EE Bad Practices: Leftover Debug Code
Abstract
Debug code can create unintended entry points in a deployed web application.
Explanation
A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.
The most common example of forgotten debug code is a
The most common example of forgotten debug code is a
main() method appearing in a web application. Although this is an acceptable practice during product development, classes that are part of a production J2EE application should not define a main().References
[1] ENV06-J. Production code must not contain debugging entry points CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 489
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[5] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[6] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.structural.java.j2ee_badpractices_leftover_debug_code