When 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.

Primary

Operation
COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.

Medium

Non-Repudiation
Hide Activities
If security critical information is not recorded, there will be no trail for forensic analysis and discovering the cause of problems or the source of attacks may become more difficult or impossible.

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Architecture and Design
Use a centralized logging mechanism that supports multiple levels of detail.

Implementation
Ensure that all security-related successes and failures can be logged. When storing data in the cloud (e.g., AWS S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to enable and capture detailed logging information.

Operation
Be sure to set the level of logging appropriately in a production environment. Sufficient data should be logged to enable system administrators to detect attacks, diagnose errors, and recover from attacks. At the same time, logging too much data (CWE-779) can cause the same problems, including unexpected costs when using a cloud environment.

Operation
To enable storage logging using Azure's Portal, navigate to the name of the Storage Account, locate Monitoring (CLASSIC) section, and select Diagnostic settings (classic). For each of the various properties (blob, file, table, queue), ensure the status is properly set for the desired logging data. If using PowerShell, the Set-AzStorageServiceLoggingProperty command could be called using appropriate -ServiceType, -LoggingOperations, and -RetentionDays arguments.

The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).

<system.serviceModel><behaviors><serviceBehaviors><behavior name="NewBehavior"><serviceSecurityAudit auditLogLocation="Default"suppressAuditFailure="false"serviceAuthorizationAuditLevel="None"messageAuthenticationAuditLevel="None" />...

</system.serviceModel>

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).

<system.serviceModel><behaviors><serviceBehaviors><behavior name="NewBehavior"><serviceSecurityAudit auditLogLocation="Default"suppressAuditFailure="false"serviceAuthorizationAuditLevel="SuccessAndFailure"messageAuthenticationAuditLevel="SuccessAndFailure" />
...

</system.serviceModel>

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.

if LoginUser(){
// Login successful
RunProgram();
} else {
// 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.

if LoginUser(){
// Login successful
log.warn("Login by user successful.");
RunProgram();
} else {

// Login unsuccessful
log.warn("Login attempt by user failed, trying again.");
LoginRetry();
}

Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:

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:

az storage logging update --account-name --account-key --services b --log rwd --retention 90

To enable Azure's storage analytic logs programmatically using PowerShell:

Set-AzStorageServiceLoggingProperty -ServiceType Queue -LoggingOperations read,write,delete -RetentionDays 5 -Context $MyContextObject

Notice that here, the retention has been limited to 5 days.

CVE-2008-4315
server does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
https://www.cve.org/CVERecord?id=CVE-2008-4315

CVE-2008-1203
admin interface does not log failed authentication attempts, making it easier for attackers to perform brute force password guessing without being detected
https://www.cve.org/CVERecord?id=CVE-2008-1203

CVE-2007-3730
default configuration for POP server does not log source IP or username for login attempts
https://www.cve.org/CVERecord?id=CVE-2007-3730

CVE-2007-1225
proxy does not log requests without "http://" in the URL, allowing web surfers to access restricted web content without detection
https://www.cve.org/CVERecord?id=CVE-2007-1225

CVE-2003-1566
web server does not log requests for a non-standard request type
https://www.cve.org/CVERecord?id=CVE-2003-1566

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CWE Content Team
MITRE
2009-07-02
1.5
2009-07-27

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated References

CWE Content Team
MITRE
2017-11-08
updated Modes_of_Introduction, Relationships

CWE Content Team
MITRE
2018-03-27
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples, Potential_Mitigations

CWE Content Team
MITRE
2023-01-31
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Relationships, Weakness_Ordinalities

Fortify Software
2009-07-02
Provided code example and additional information for description and consequences.

Drew Buttner
MITRE
2022-08-15
Suggested a new demonstrative example and changes to the mitigations.