Console.log statements are cleaned up

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.

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

// .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.

• ID: pre-launch.final-verification.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:

  // 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:

     // .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.