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.