This weakness occurs when an application writes sensitive data—such as passwords, API keys, authentication tokens, or personal information—directly into log…
This weakness occurs when an application writes sensitive data—such as passwords, API keys, authentication tokens, or personal information—directly into log files. Because logs are often stored in accessible locations, backed up, or shipped to centralized logging systems, this creates a secondary exposure channel that bypasses the primary security controls protecting the original data. Even if the application itself is secure, unguarded logs can leak secrets to anyone with file system or log aggregation access.
02How It Happens
Developers often log user input, request parameters, or system state for debugging and monitoring purposes. When this logging is done without filtering, sensitive fields get written verbatim into log output. This is especially common in error handlers (which may dump entire request objects), authentication flows (which may log credentials during failed login attempts), or third-party API integrations (which may log full request/response bodies including tokens). The assumption that "logs are internal" leads to a false sense of security—in practice, logs are accessed by support staff, stored in backups, forwarded to external monitoring services, and sometimes exposed through misconfigured log viewers or log aggregation platforms.
03Real-World Impact
Compromised logs can lead to account takeover if passwords or session tokens are exposed, unauthorized API access if keys are leaked, and identity theft or privacy violations if personal data (SSNs, credit card numbers, email addresses) is logged. Unlike a direct database breach, log exposure is often discovered late because logs are not typically monitored for sensitive content. An attacker with read access to logs—whether through a web shell, backup theft, or misconfigured log aggregation service—gains the same secrets as if they had breached the primary data store.
04Vulnerable & Fixed Patterns
Vulnerable pattern
import logging
logging.basicConfig(filename='app.log', level=logging.DEBUG)
def authenticate_user(username, password):
logging.debug(f"Login attempt: username={username}, password={password}")
# ... authentication logic ...
if not user_found:
logging.error(f"Auth failed for user {username} with password {password}")
return authenticated
Why it's vulnerable: The password is logged in plaintext in both the debug and error messages. Anyone with access to app.log can read user credentials.
Fixed pattern
import logging
logging.basicConfig(filename='app.log', level=logging.DEBUG)
def authenticate_user(username, password):
logging.debug(f"Login attempt: username={username}")
# ... authentication logic ...
if not user_found:
logging.error(f"Auth failed for user {username}")
return authenticated
Why it's vulnerable: The password from the POST request is written directly to the error log. Any process or person with log file access can read plaintext credentials.
Fixed pattern
<?php
error_log("User login attempt: " . sanitize_username($_POST['username']));
if (!authenticate($_POST['username'], $_POST['password'])) {
error_log("Failed login for user: " . sanitize_username($_POST['username']));
}
?>
05Prevention Checklist
Identify sensitive fields — Maintain a list of data types that should never be logged: passwords, API keys, tokens, credit card numbers, SSNs, email addresses, and personally identifiable information (PII).
Filter at the source — Before logging any user input or request data, explicitly exclude or redact sensitive fields. Use allowlists (log only safe fields) rather than blocklists.
Sanitize error messages — Ensure exception handlers and error logs do not dump entire request objects, stack traces with variable contents, or database query results.
Mask sensitive values in logs — If a field must be logged for audit purposes, log only a hash, a truncated version, or a placeholder (e.g., token=*REDACTED *).
Restrict log file access — Limit file system permissions on log files to the application user and trusted administrators; do not make logs world-readable.
Audit log aggregation pipelines — If logs are forwarded to external services (Splunk, CloudWatch, ELK), ensure those services are also properly secured and that sensitive data is redacted before transmission.
06Signs You May Already Be Affected
Review your application logs for plaintext passwords, API keys, or tokens. Search log files for common sensitive patterns (e.g., password=, token=, Authorization:, api_key=). Check whether support staff, developers, or third-party services have access to logs and whether that access is logged or audited. If you find sensitive data in logs, assume it may have been accessed by unauthorized parties and rotate affected credentials immediately.
