Insufficient logging occurs when an application fails to record security-relevant events or records them without enough detail to detect or investigate…
Insufficient logging occurs when an application fails to record security-relevant events or records them without enough detail to detect or investigate suspicious activity. Without adequate logs, attackers can operate undetected, and when a breach is discovered, there is little evidence to understand what happened, how long it lasted, or what data was affected.
Applications often prioritize functionality over audit trails. Developers may skip logging for performance reasons, assume that "nothing bad will happen," or simply not consider which events matter for security. Common gaps include: no record of failed login attempts, no logging of administrative actions, no timestamps on sensitive operations, no user identification in logs, or logs that are immediately overwritten without retention. Even when logs exist, they may lack context—recording that "an error occurred" without noting *which user*, *what action*, or *what data* was involved makes investigation nearly impossible.
Insufficient logging directly enables attackers to hide their tracks. An attacker who gains access to an account can modify data, steal information, or plant malware without leaving a detectable trail. When a breach is eventually discovered through external means (a customer complaint, a third-party alert), the organization cannot determine the scope of the compromise, which accounts were affected, or when the intrusion began. This delays incident response, increases recovery costs, and may violate compliance requirements (HIPAA, PCI-DSS, SOC 2) that mandate audit trails. In regulated industries, the inability to prove what happened can result in fines and loss of trust.
def authenticate_user(username, password):
user = database.query("SELECT * FROM users WHERE username = ?", (username,))
if user and check_password(password, user['password_hash']):
session['user_id'] = user['id']
return True
return False
def delete_user_account(user_id):
database.execute("DELETE FROM users WHERE id = ?", (user_id,))
return TrueWhy it's vulnerable:
Neither authentication attempts nor administrative actions (like account deletion) are recorded. A successful login leaves no trace, failed attempts are invisible, and there is no record of who deleted which account or when.
import logging
from datetime import datetime
logger = logging.getLogger(__name__)
def authenticate_user(username, password):
user = database.query("SELECT * FROM users WHERE username = ?", (username,))
if user and check_password(password, user['password_hash']):
session['user_id'] = user['id']
logger.info(f"Successful login for user_id={user['id']}, username={username}, ip={request.remote_addr}")
return True
logger.warning(f"Failed login attempt for username={username}, ip={request.remote_addr}")
return False
def delete_user_account(user_id, admin_id):
database.execute("DELETE FROM users WHERE id = ?", (user_id,))
logger.info(f"Account deleted: user_id={user_id}, deleted_by_admin_id={admin_id}, timestamp={datetime.utcnow().isoformat()}")
return True<?php
function authenticate_user($username, $password) {
$user = $wpdb->get_row("SELECT * FROM users WHERE username = '$username'");
if ($user && password_verify($password, $user->password_hash)) {
$_SESSION['user_id'] = $user->id;
return true;
}
return false;
}
function delete_user_account($user_id) {
$wpdb->query("DELETE FROM users WHERE id = $user_id");
return true;
}
?>Why it's vulnerable:
No logging of login attempts (successful or failed), no record of who performed the deletion, no timestamps, and no way to audit administrative actions.
<?php
function authenticate_user($username, $password) {
$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM users WHERE username = %s", $username));
if ($user && password_verify($password, $user->password_hash)) {
$_SESSION['user_id'] = $user->id;
error_log("Successful login: user_id={$user->id}, username={$username}, ip={$_SERVER['REMOTE_ADDR']}, time=" . date('Y-m-d H:i:s'));
return true;
}
error_log("Failed login attempt: username={$username}, ip={$_SERVER['REMOTE_ADDR']}, time=" . date('Y-m-d H:i:s'));
return false;
}
function delete_user_account($user_id, $admin_id) {
$wpdb->query($wpdb->prepare("DELETE FROM users WHERE id = %d", $user_id));
error_log("Account deleted: user_id={$user_id}, deleted_by_admin_id={$admin_id}, time=" . date('Y-m-d H:i:s'));
return true;
}
?>Review your application logs for gaps: if you cannot answer "who accessed this account," "when was this data modified," or "what administrative actions occurred in the last 24 hours," logging is insufficient. Check whether logs are being overwritten too quickly, stored in a location accessible to the application itself (where an attacker could delete them), or missing timestamps and user identifiers. If your incident response team has ever said "we don't know how long the attacker was in the system," that is a direct sign of inadequate logging.
