# Console.log statements are cleaned up

- **Pattern:** `ab-002170` (`pre-launch.final-verification.console-logs-cleaned`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002170
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002170)

## Why it matters

Development `console.log` statements left in production code expose internal data structures, API response shapes, and occasionally user data or credentials in the browser's developer tools — visible to any technically literate user who opens DevTools. CWE-215 and CWE-532 both describe information exposure through debug output. Beyond security, dense console output in server-side code inflates log storage costs and buries legitimate error signals, making production incidents harder to diagnose. Console logs that capture user form data or authentication tokens are a compliance risk under GDPR data minimization requirements.

## Severity rationale

Low because the risk is primarily information disclosure to curious users with DevTools open, but console calls logging user data or tokens can escalate to a compliance issue under CWE-532.

## Remediation

Scan for debug logs across production source files, remove non-essential ones, and add an ESLint rule to prevent future regressions.

```json
// .eslintrc.json — flag console.log in production code
{ "rules": { "no-console": ["warn", { "allow": ["error", "warn"] }] } }
```

Search for logs: `grep -r "console.log" src/` (or `app/`). Keep only deliberate `console.error` calls in error handlers and monitoring integrations — these serve a production purpose. For structured server-side logging, replace `console.log` with Pino or Winston configured to emit JSON at `warn`/`error` level in production. Add the ESLint `no-console` rule to `eslint.config.js` or `.eslintrc` to catch new additions in code review.

## Detection

- **ID:** `console-logs-cleaned`
- **Severity:** `low`
- **What to look for:** Count all `console.log`, `console.warn`, `console.debug`, and `console.error` statements in production code. Enumerate which are intentional (error monitoring) vs. development leftovers. Search source code files for `console.log(`, `console.debug(`, `console.dir(` statements in production code paths. Exclude files in `__tests__`, `*.test.ts`, `*.spec.ts`, and development-only utilities. Look for console calls that might log sensitive data (user objects, API responses, form data). Check if there's an ESLint rule configured to flag console usage (`no-console` rule).
- **Pass criteria:** No significant `console.log` statements in production code paths, OR all console usage is appropriate for production (error logging via `console.error` in error handlers counts as acceptable). No more than 5 intentional console statements in production code. Zero `console.log` or `console.debug` in page/API components.
- **Fail criteria:** Multiple `console.log` statements in business logic, API handlers, or component files that would produce noise in production logs. Any console calls that appear to log sensitive user data.
- **Skip (N/A) when:** Never — this applies to all projects with JavaScript/TypeScript source code.

- **Cross-reference:** For debug mode, see `debug-mode-disabled`.
- **Detail on fail:** `"Multiple console.log statements found in production code paths — generates log noise and may expose sensitive data in browser devtools"`
- **Remediation:** Development console logs become noise in production and can accidentally expose sensitive data in browser devtools:

  ```js
  // eslint.config.js — warn on console usage
  { rules: { "no-console": ["warn", { allow: ["error"] }] } }
  ```

  1. Search for and remove debug logs: `grep -r "console.log" src/` (or your source directory).
  2. Keep only deliberate `console.error` calls in error handlers — these serve a production purpose.
  3. Add an ESLint rule to prevent future regressions:
     ```json
     // .eslintrc.json
     { "rules": { "no-console": ["warn", { "allow": ["error", "warn"] }] } }
     ```
  4. Consider using a proper logging library (Pino, Winston) for server-side logging that can be configured per environment.

## External references

- cwe CWE-215
- cwe CWE-532

Taxons: placeholder-hygiene, observability

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