console.log calls accumulated during debugging become three problems at once in production: they ship user data (tokens, emails, request bodies) to the browser devtools console where any script running on the page can read them, they bloat server logs with unstructured strings that drown out real errors, and they frequently contain the exact console.log(user) style dumps that leak entire auth objects into logs your observability stack indexes. AI coding tools produce this failure mode prolifically because logging is the default debugging tool they reach for — "let me add a console.log to see what's happening here" — and multi-session work accumulates these without cleanup. The threshold of 10 allows for intentional structured-logging adapters while flagging the codebase-wide pattern where debug instrumentation never got removed.
Medium because scattered console.log calls can leak user data to the browser console and to indexed server logs, but the exposure is usually opportunistic rather than structurally exploitable.
Replace with a structured logger (pino, winston) or remove. Configure the build to strip logs in production:
// next.config.js
compiler: { removeConsole: process.env.NODE_ENV === 'production' }
Deeper remediation guidance and cross-reference coverage for this check lives in the code-quality-essentials Pro audit — run that after applying this fix for a more exhaustive pass on the same topic.
project-snapshot.code-quality.no-console-logsmediumconsole.log, console.debug, console.info call in source files (excluding test files, build scripts, and console.error/console.warn which are appropriate for production). Count.console.log/console.debug/console.info calls in production source files."Scanned ~N source files (excluding tests); found M console.log/debug/info calls.""24 console.log calls in production source; examples: src/lib/users.ts (4 calls), components/checkout/payment.tsx (3 calls)".// next.config.js
compiler: { removeConsole: process.env.NODE_ENV === 'production' }