CWE-778: Insufficient Logging
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterWhen a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
When security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds. As organizations adopt cloud storage resources, these technologies often require configuration changes to enable detailed logging information, since detailed logging can incur additional costs. This could lead to telemetry gaps in critical audit logs. For example, in Azure, the default value for logging is disabled. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Example 1 The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF). (bad code)
Example Language: XML
<system.serviceModel>
<behaviors> </system.serviceModel><serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Default" ...suppressAuditFailure="false" serviceAuthorizationAuditLevel="None" messageAuthenticationAuditLevel="None" /> The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts. Logging failed authentication attempts can warn administrators of potential brute force attacks. Similarly, logging successful authentication events can provide a useful audit trail when a legitimate account is compromised. The following configuration shows appropriate settings, assuming that the site does not have excessive traffic, which could fill the logs if there are a large number of success or failure events (CWE-779). (good code)
Example Language: XML
<system.serviceModel>
<behaviors> </system.serviceModel><serviceBehaviors>
<behavior name="NewBehavior">
<serviceSecurityAudit auditLogLocation="Default"
...suppressAuditFailure="false" serviceAuthorizationAuditLevel="SuccessAndFailure" messageAuthenticationAuditLevel="SuccessAndFailure" /> Example 2 In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program. (bad code)
Example Language: Java
if LoginUser(){
// Login successful
} else {
RunProgram(); // Login unsuccessful
}LoginRetry(); It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message. (good code)
Example Language: Java
if LoginUser(){
// Login successful
} else {
log.warn("Login by user successful."); RunProgram();
// Login unsuccessful
}log.warn("Login attempt by user failed, trying again."); LoginRetry(); Example 3 Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]: (bad code)
Example Language: Shell
az storage logging update --account-name --account-key --services b --log d --retention 90
The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue: (good code)
Example Language: Shell
az storage logging update --account-name --account-key --services b --log rwd --retention 90
To enable Azure's storage analytic logs programmatically using PowerShell: (good code)
Example Language: Shell
Set-AzStorageServiceLoggingProperty -ServiceType Queue -LoggingOperations read,write,delete -RetentionDays 5 -Context $MyContextObject
Notice that here, the retention has been limited to 5 days.
![]()
More information is available — Please edit the custom filter or select a different filter. |
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |