TLDR: Misconfigured logging of internal class names can expose sensitive implementation details, including application structure, dependencies, and logic. This information leakage can aid attackers in reconnaissance, leading to vulnerabilities such as data leakage, remote code execution (RCE), and code injection. These risks arise from improper logging configurations and lack of sanitization, violating several OWASP Top Ten principles, including secure Logging, Error Handling, and Access Controls.
https://owasp.org/www-community/Logging_and_Monitoring_Cheat_Sheet
Logging detailed internal class names without sanitization can reveal the structure of the application, including its Java classes, frameworks, and libraries. This disclosure enables attackers to target specific components, violating the OWASP Top Ten's principle of secure Error Handling by exposing unnecessary details to external users.
https://owasp.org/www-community/Error_Handling
Exposing class names and dependencies in logs can inadvertently disclose vulnerabilities in outdated libraries or frameworks. This information can be used for dependency-checking attacks. Regular alerts for vulnerable components and sanitizing logs mitigate this risk, aligning with OWASP Top Ten standards.
https://owasp.org/www-project-dependency-check/
Improperly controlled access to logs containing internal class names can lead to unauthorized use of this information for exploitation. Ensuring logs are secured with robust Access Controls prevents unauthorized individuals from viewing sensitive internal data, following OWASP Top Ten's Access Management recommendations.
https://owasp.org/www-community/Access_Control
Logging internal class names without context or sanitization can enable attackers to map the application’s logic. These details can facilitate code injection attacks if the attacker identifies weaknesses. Avoiding logging of unnecessary internal details complies with OWASP Top Ten's secure Logging practices.
https://owasp.org/www-community/OWASP_Proactive_Controls
Over-reliance on default logging configurations in frameworks often results in verbose logs that include unnecessary details such as internal class names and stack traces. Reviewing and customizing Framework Defaults ensures compliance with OWASP Top Ten's best practices for secure configuration.
https://owasp.org/www-community/Framework_Security_Project
Logging internal class names without limits on the size or frequency of logs can result in excessive storage usage or system resource exhaustion. This increases the risk of denial of service attacks. Implementing quotas and rate-limiting for logging ensures compliance with OWASP Top Ten's resource management principles.
https://owasp.org/www-community/Denial_of_Service
Including internal class names in logs during CORS-related error responses can expose sensitive application details to untrusted origins. Ensuring proper Policy Enforcement and sanitizing error messages mitigates this risk, aligning with OWASP Top Ten's guidelines for secure API management.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Neglecting to encrypt logs that include internal class names increases the risk of exposure during transport or unauthorized access. Encrypting logs and using secure protocols, such as TLS, ensures compliance with OWASP Top Ten's Data Encryption standards.
https://owasp.org/www-community/Data_Encryption
Lastly, failing to segregate environments for logging internal class names allows sensitive debug information from development to be exposed in production. Adopting environment-specific logging practices reduces the risk of exposing implementation details and adheres to OWASP Top Ten's operational best practices.