console.log() in Production: How Debug Statements Leak User Data and Secrets

How Debug Statements Become Data Leaks

When you prompt an AI tool to build a login form, it adds console.log() for debugging. When you ask for Stripe integration, it logs the full webhook payload. When you build an API, it logs every request body. These statements are invisible to the UI, but they create persistent data exposure in two places: the browser console (client-side) and server/container logs (server-side).

GitGuardian's State of Secrets Sprawl 2023 found 10 million new secrets exposed on GitHub in 2022 alone. Security logging and alerting failures are A09 in the OWASP Top 10 (2025), but excessive logging of sensitive data is equally dangerous.

What AI-Generated Code Logs

// ❌ BAD - Typical AI-generated auth handler
app.post('/api/login', async (req, res) => {
  console.log('Login request:', req.body);
  // Logs: { email: "user@email.com", password: "MyP@ssw0rd!" }

  const user = await db.users.findByEmail(req.body.email);
  console.log('Found user:', user);
  // Logs: { id: 1, email: "...", passwordHash: "...", ssn: "..." }

  const token = generateToken(user);
  console.log('Generated token:', token);
  // Logs: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

  res.json({ token });
});

// ✅ GOOD - Structured logging without sensitive data
import pino from 'pino';
import bcrypt from 'bcrypt';
const logger = pino({ level: process.env.LOG_LEVEL || 'info' });

app.post('/api/login', async (req, res) => {
  logger.info({ email: req.body.email }, 'Login attempt');
  // Logs: { email: "user@email.com", msg: "Login attempt" }
  // Never logs password, token, or full user object

  const user = await db.users.findByEmail(req.body.email);
  const valid = user && await bcrypt.compare(req.body.password, user.passwordHash);
  if (!valid) {
    logger.warn({ email: req.body.email }, 'Login failed');
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  const token = generateToken(user);
  logger.info({ userId: user.id }, 'Login successful');
  // Only logs a non-sensitive identifier

  res.json({ token });
});

The Three Places Your Logs Leak

Sensitive Data Types Found in Logs

How to Remove and Prevent Log Leaks

1. Search your entire codebase for console.log, console.debug, console.warn, and console.error. Remove any that log request bodies, user objects, tokens, or API responses.
2. Use a structured logger like Pino or Winston. Structured loggers make it easy to control what fields are included and support log-level filtering per environment.
3. Add an ESLint rule: "no-console": "error" to catch new console.log statements at build time.
4. Configure log levels: Use debug level for development and info or warn for production. Never deploy with debug-level logging enabled.
5. Redact sensitive fields in your logger configuration. Pino supports redact: ['req.headers.authorization', 'req.body.password'].
6. Scan automatically. VibeDoctor's Vibe Check flags every console.log and console.debug call in JavaScript and TypeScript code outside tests, scripts, docs and examples, with the file and line. In Python web apps it flags files with more than five print() calls and no logging library (CFG-006). It flags the call, not what it logs, so the redaction steps above still matter. Free to sign up.

ESLint Configuration to Block console.log

ESLint 10 only reads the flat config file, eslint.config.js. The old .eslintrc.json format is no longer supported.

// eslint.config.js
export default [
  {
    rules: {
      'no-console': ['error', { allow: ['warn', 'error'] }],
    },
  },
];

// For files where you need console.log (dev scripts, CLIs):
// eslint-disable-next-line no-console
console.log('This is intentional');

FAQ