This weakness occurs when an application logs too much information—particularly sensitive data like passwords, API keys, personal identifiers, or full…
This weakness occurs when an application logs too much information—particularly sensitive data like passwords, API keys, personal identifiers, or full request/response bodies—making logs a liability rather than a security tool. Excessive logging can also obscure genuinely important security events under noise, making incident detection and forensics harder. Both problems create risk: exposed logs become an attack surface, and buried signals delay response.
Developers often enable verbose logging during development or debugging and forget to dial it back before production. Alternatively, they log entire user inputs, HTTP headers, or database queries without filtering, assuming logs are "internal only" and therefore safe. In reality, logs are frequently stored in multiple places (application servers, centralized logging systems, backups, container registries), accessed by multiple teams, and sometimes accidentally exposed via misconfigured cloud storage, version control, or log aggregation dashboards. The combination of overly detailed logging and broad access creates a window for sensitive data to leak.
If logs contain plaintext passwords, session tokens, or API credentials, anyone with read access to logs—including junior developers, contractors, or attackers who breach a log storage system—can impersonate users or access backend services. Logs containing full credit card numbers, social security numbers, or health information can trigger regulatory violations (GDPR, HIPAA, PCI-DSS) and breach notification requirements. Even without sensitive data, excessive logging can fill storage quickly, increasing costs and making it harder to retain logs long enough for forensics or compliance audits.
import logging
logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)
def authenticate_user(username, password):
logger.debug(f"Authentication attempt: user={username}, password={password}")
# ... authentication logic ...
logger.info(f"User logged in: {username}, session_token={session_token}")
return session_token
def process_payment(card_number, amount):
logger.debug(f"Processing payment: card={card_number}, amount={amount}")
# ... payment logic ...Why it's vulnerable:
The code logs plaintext passwords, session tokens, and full credit card numbers. These logs are typically stored on disk and may be accessed by multiple people or systems, turning logs into a data exposure vector.
import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
def authenticate_user(username, password):
logger.info(f"Authentication attempt for user: {username}")
# ... authentication logic ...
logger.info(f"User logged in: {username}")
return session_token
def process_payment(card_number, amount):
# Log only the last 4 digits and amount, never the full card number
card_last_four = card_number[-4:]
logger.info(f"Processing payment: card_last_four={card_last_four}, amount={amount}")
# ... payment logic ...<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
function handle_login($username, $password) {
error_log("Login attempt: username=$username, password=$password");
// ... authentication logic ...
error_log("User logged in: $username, session_id=$_SESSION['id'], token=$auth_token");
}
function process_form($user_input) {
error_log("Form data received: " . print_r($_POST, true));
// ... form processing ...
}
?>Why it's vulnerable:
The code logs plaintext passwords, session IDs, and full POST data without filtering. The print_r($_POST, true) pattern is especially dangerous because it logs all user input indiscriminately, including sensitive fields.
<?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
ini_set('log_errors', 1);
function handle_login($username, $password) {
error_log("Login attempt for user: $username");
// ... authentication logic ...
error_log("User logged in: $username");
}
function process_form($user_input) {
$safe_keys = ['name', 'email'];
$safe_data = array_intersect_key($_POST, array_flip($safe_keys));
error_log("Form data received: " . json_encode($safe_data));
// ... form processing ...
}
?>INFO or WARN by default; reserve DEBUG for local development only. Never ship code with DEBUG enabled in production.
Review your application logs for plaintext passwords, API keys, session tokens, or full request bodies. Check your logging configuration files and code for DEBUG level enabled in production, or for patterns like print_r($_POST) or json.dumps(request.data) without filtering. If you find sensitive data in logs, assume it may have been accessed and consider rotating credentials, notifying affected users, and checking for unauthorized access in your logs.
