No debug logging in production
Why it matters
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.
Severity rationale
Low because debug logging in production inflates cost and occasionally leaks internal state, but does not directly enable attack vectors or data loss.
Remediation
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.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Logging & Monitoring Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-779 — Logging of Excessive Data
- nist:rev5 · AU-11 — Audit Record Retention
- iso-25010:2011 · performance-efficiency
Taxons
History
- 2026-04-18·v1.0.0·Initial import from saas-logging·automated