Regra
Remover depuração e temporário temporários antes de confirmações. 
Código que contorna a lógica, produz depuração informação,
ou pára a execução para depuração era provavelmente 
deixada para trás acidentalmente durante o desenvolvimento.

Idiomas suportados: 45+

Introdução

Código de depuração, consola.log() declarações, lógica comentada, valores de teste codificados ou depurador breakpoints, são enviados para produção com mais frequência do que a maioria das equipas admite. Estes artefactos expõem o estado interno da aplicação, criam sobrecarga de desempenho e indicam aos atacantes quais as partes da sua base de código que foram problemáticas durante o desenvolvimento. O que começa como código temporário para resolução de problemas torna-se um risco de segurança permanente se não for removido antes da implementação.

Porque é importante

Implicações para a segurança: O código de depuração na produção regista frequentemente dados sensíveis, como credenciais de utilizador, chaves de API ou PII, que não devem chegar aos registos de produção.
A consola.log(utilizador) pode descarregar um objeto de utilizador inteiro, incluindo tokens de sessão, na consola do navegador ou nos registos do servidor acessíveis ao pessoal de apoio ou a ferramentas de agregação de registos. Esta é uma das vulnerabilidades de segurança de código mais comuns que as ferramentas de revisão automática de código detectam.

Impacto no desempenho: O registo excessivo da consola cria um estrangulamento de E/S. Um ponto de extremidade de alto tráfego que registra cargas úteis de solicitação de log pode degradar os tempos de resposta em 15 a 30 ms por solicitação e aumentar os custos de armazenamento de log. O impacto no desempenho do registo em ambientes de produção Node.js aumenta rapidamente em escala.

Manutenção do código: Confirmações temporárias de código como se (verdadeiro) retornar; ou
‍// TODO: fix later contornam a lógica empresarial e criam confusão para os futuros responsáveis pela manutenção. Representam uma dívida técnica sem rasto documental.

Expansão da superfície de ataque: As instruções do depurador e o registo de erros detalhado revelam traços de pilha, caminhos de ficheiros, versões de dependências e fluxo lógico interno, informações úteis para reconhecimento durante ataques direcionados.

Exemplos de código

Não conforme:

async function processPayment(userId, amount) {
  console.log('Processing payment:', { userId, amount });

  const user = await db.users.findById(userId);
  console.log('User data:', user); // Logs email, tokens, everything

  debugger;

  const result = await paymentGateway.charge({
    userId: user.id,
    amount: amount
  });

  console.log('Gateway response:', result);
  return result;
}

Porque é que isto não é seguro: As instruções de consola registam PII (Informações Pessoais Identificáveis) e tokens de autenticação nos registos de produção. O depurador comentado cria ambiguidade sobre os caminhos de execução. Todos esses dados são acessíveis a qualquer pessoa com acesso ao log e fornecem aos invasores dados de reconhecimento.

Conformidade:

async function processPayment(userId, amount) {
  const user = await db.users.findById(userId);

  if (!user) {
    throw new PaymentError('User not found');
  }

  const result = await paymentGateway.charge({
    userId: user.id,
    amount: amount
  });

  await auditLog.record({
    event: 'PAYMENT_PROCESSED',
    userId: userId,
    transactionId: result.transactionId
  });

  return result;
}

Porque é que isto é seguro: O registo estruturado substitui consola.log com pistas de auditoria adequadas que captam eventos comerciais sem expor dados sensíveis do utilizador. Não existem instruções de depuração. A lógica flui linearmente sem desvios condicionais. Os registos de auditoria são centralizados, controlados por acesso e contêm apenas o contexto necessário para conformidade e depuração.

Conclusão

O código de depuração em produção não é um problema menor, é uma vulnerabilidade de segurança, uma responsabilidade de desempenho e um fardo de manutenção. Seguir as práticas recomendadas de revisão de código seguro significa detetar esses problemas antes que eles cheguem ao seu ramo principal. As regras automatizadas de qualidade do código devem impedir que o código de depuração chegue ao controlo de versões, quanto mais à produção. O segredo é ter as ferramentas certas para detetar esses problemas antes que eles sejam mesclados.