# Debug logs do not output sensitive user data to console

- **Pattern:** `ab-001316` (`extension-data-privacy.third-party-sharing.console-debug-logs`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001316
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001316)

## Why it matters

DevTools console output is visible to anyone with access to the browser — shared workstations, screen recordings, bug reports, and automated testing pipelines all routinely capture console output. Logging an auth token, user email, or session ID turns every debug session into a credential exposure event. CWE-200 and CWE-532 (Insertion of Sensitive Information into Log File) both apply; OWASP 2021 A09 (Security Logging and Monitoring Failures) includes logging sensitive data as a primary failure mode. Extension console output is also visible to any page script that exploits a content script bridge, making it a secondary exfiltration vector beyond direct log viewing.

## Severity rationale

Low because console log exposure requires DevTools access or a screen share to exploit — but it is a persistent risk in shared environments and turns routine debugging into a credential leak that may not be noticed until after the fact.

## Remediation

Audit all `console.log`, `console.error`, and `console.warn` calls and redact any values that contain PII, tokens, or API keys:

```js
// BAD — logs full user object including sensitive fields
const user = { email: 'user@example.com', token: 'Bearer sk-abc123' };
console.log('Authenticated user:', user);

// GOOD — log only non-sensitive diagnostics
console.log('User authenticated successfully');

// For development-only detail, gate behind environment check
if (process.env.NODE_ENV === 'development') {
  console.debug('Auth state:', { userId: user.id }); // userId only, no token
}
```

Consider using a structured logger that strips configured sensitive keys automatically rather than relying on manual review of individual log statements.

## Detection

- **ID:** `console-debug-logs`
- **Severity:** `low`
- **What to look for:** Search the codebase for `console.log`, `console.error`, `console.warn` statements. Check whether any logged values include user data, PII, passwords, tokens, or email addresses. Look for patterns like `console.log({ user })` or `console.error('Auth token:', token)`.
- **Pass criteria:** Count all `console.log`, `console.error`, `console.warn` statements across the codebase. Debug logs do not output sensitive user data, tokens, passwords, or PII. 0% of log statements may include PII or secrets. If logging is used, only non-sensitive diagnostic information is logged (e.g., feature flags, timing, state machine transitions).
- **Fail criteria:** Sensitive data (emails, tokens, user IDs, encrypted data) is logged to console via `console.log`, `console.error`, etc. Passwords or API keys visible in debug output.
- **Skip (N/A) when:** Never — console output is a critical attack surface.
- **Detail on fail:** Identify the logged data. Example: `"console.log(authToken) outputs bearer token to extension console, visible in devtools"` or `"Error handler logs entire user object including email and preferences to console."`
- **Remediation:** Remove sensitive data from logs:

  ```js
  // BAD
  const user = { email: 'user@example.com', token: 'secret' };
  console.log(user);

  // GOOD
  console.log('User authenticated'); // No data
  if (process.env.NODE_ENV === 'development') {
    console.debug('User:', { email: user.email }); // Redact token
  }
  ```

## External references

- cwe CWE-200
- cwe CWE-532
- owasp A09

Taxons: cryptography-and-secrets, privacy-consent

HTML version: https://auditbuffet.com/patterns/ab-001316