CWE-779 (Logging of Excessive Data) identifies verbose debug output in production as a logging misconfiguration with real costs: inflated log ingestion bills, slower log shipping, and inadvertent exposure of internal state that debug-level entries often contain. NIST AU-11 covers log retention and volume management — producing debug output in production that you don't need directly increases retention costs without increasing observability value. The secondary risk is that debug output frequently captures internal parameter values, function inputs, and intermediate state that are inappropriate for a production log store. A hardcoded level: 'debug' in your logger config means your production environment is behaving like a development instance.
Low because debug logging in production inflates cost and occasionally leaks internal state, but does not directly enable attack vectors or data loss.
Control log level through an environment variable so you can raise verbosity for debugging without a code change or redeploy.
// lib/logger.ts
const logger = pino({
level: process.env.LOG_LEVEL ?? 'info', // 'debug' in dev, 'info' in prod
})
Set LOG_LEVEL=info in your production hosting environment (Vercel project settings, Fly.io secrets, Railway variables). Set LOG_LEVEL=debug in .env.local for local development. Add LOG_LEVEL=info to .env.example so the convention is documented for other developers.
ID: saas-logging.app-logging.no-debug-production
Severity: low
What to look for: Enumerate all relevant files and Check logging configuration for how debug-level output is controlled. Look for LOG_LEVEL environment variable usage, logger configuration that reads from environment, or hardcoded log level settings. Specifically look for: level: 'debug' hardcoded without an environment condition, logger.debug(...) calls that would fire in production, or console.log / console.debug calls that aren't guarded by a development environment check. Also check .env.example for a LOG_LEVEL variable.
Pass criteria: No more than 0 violations are acceptable. Logger is configured to use info level or higher in production, either via environment variable (LOG_LEVEL=info in production env) or hardcoded non-debug level. Debug calls are either absent or gated behind an environment check.
Fail criteria: Logger is hardcoded to debug level without environment gating, OR no log level configuration exists at all (defaulting to the library's debug-level default).
Skip (N/A) when: No logging library and no meaningful console.log usage in server-side code.
Detail on fail: Example: "pino configured with level: 'debug' hardcoded in lib/logger.ts — will emit verbose debug output in production" or "No LOG_LEVEL environment variable; logger defaults to debug level"
Remediation: Debug-level output in production bloats your log storage (and bills), slows down your application, and can inadvertently expose verbose internal data. Set the log level via environment variable so you can turn it up when debugging without redeploying.
// lib/logger.ts
const logger = pino({
level: process.env.LOG_LEVEL ?? 'info', // debug in dev, info in prod
})
In your hosting platform's production environment variables, set LOG_LEVEL=info. In development, set LOG_LEVEL=debug in .env.local. Add LOG_LEVEL=info to your .env.example as documentation.