Sensitive Data in Logs

Also Known As

TL;DR

Explanation

Application logs are collected by aggregators (ELK, Datadog, Splunk) where they are stored, indexed, and accessed by many more people than the primary database. Logging request parameters, exception messages containing credentials, or full user objects routinely exposes sensitive data. Structured logging makes this worse — a well-intentioned context object dumps everything. Always explicitly allowlist what gets logged rather than logging everything and filtering after.

Common Misconception

Why It Matters

Common Mistakes

• Logging entire request arrays: error_log(print_r($_POST, true)) — captures passwords and tokens.
• Logging exception messages that include SQL with bound parameters containing user data.
• Logging full user objects including hashed passwords and API keys.
• Not masking card numbers — only log last 4 digits: ****1234.

Code Examples

// Logs entire POST including passwords:
error_log('Request: ' . print_r($_POST, true));

// Logs exception with credentials in message:
try {
    authenticate($user, $password);
} catch (Exception $e) {
    $logger->error($e->getMessage()); // May contain password
    $logger->debug('Context', ['user' => $user, 'pass' => $password]);
}

// Explicit allowlist — only log safe fields:
$logger->info('Login attempt', [
    'user_id' => $user->id,
    'ip'      => $request->ip(),
    'success' => $authenticated,
    // No password, no token, no PII beyond user_id
]);

// Mask sensitive values:
$logger->debug('Payment', [
    'card_last4' => substr($card, -4),
    'amount'     => $amount,
    // Never: full card number, CVV, or auth token
]);

References

• ↗ https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

Tags

Related Terms