Règle
Supprimer débogage et temporaire temporaire avant les les commits. 
Le code qui contourne logique, produit débogage de débogage,
ou arrête l'exécution pour débogage était probablement 
laissée derrière accidentellement au cours du développement.

Langues prises en charge : 45+

Introduction

Code de débogage, console.log() instructions, logique commentée, valeurs de test codées en dur, ou debugger les points d'arrêt, sont livrés en production plus souvent que la plupart des équipes ne l'admettent. Ces artefacts exposent l'état interne de l'application, créent une surcharge de performance et signalent aux attaquants quelles parties de votre codebase étaient problématiques pendant le développement. Ce qui commence comme du code temporaire pour le dépannage devient un risque de sécurité permanent s'il n'est pas supprimé avant le déploiement.

Pourquoi c'est important

Implications en matière de sécurité : Le code de débogage en production enregistre souvent des données sensibles comme les identifiants utilisateur, les clés API ou les PII qui ne devraient pas atteindre les logs de production.
A console.log(user) une instruction pourrait décharger un objet utilisateur complet, y compris les jetons de session, dans la console du navigateur ou les journaux du serveur, accessibles au personnel de support ou aux outils d'agrégation de logs. C'est l'une des vulnérabilités de sécurité de code les plus courantes que les outils d'analyse de code automatisée détectent.

Impact sur les performances: La journalisation excessive dans la console crée un goulot d'étranglement I/O. Un point de terminaison à fort trafic enregistrant les charges utiles des requêtes peut dégrader les temps de réponse de 15 à 30 ms par requête et augmenter considérablement les coûts de stockage des logs. L'impact sur les performances de la journalisation dans les environnements de production Node.js s'aggrave rapidement à grande échelle.

Maintenabilité du code : Commits de code temporaires comme if (true) return; ou
‍// TODO: fix later contournent la logique métier et créent de la confusion pour les futurs mainteneurs. Ils représentent une dette technique sans trace de documentation.

Expansion de la surface d'attaque : Les instructions de débogage et la journalisation d'erreurs verbale révèlent les traces de pile, les chemins de fichiers, les versions des dépendances et le flux logique interne, des informations utiles pour la reconnaissance lors d'attaques ciblées.

Exemples de code

❌ Non 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;
}

Pourquoi c'est dangereux : Les instructions de console enregistrent des PII (informations personnellement identifiables) et des jetons d'authentification dans les logs de production. Le débogueur commenté crée une ambiguïté sur les chemins d'exécution. Toutes ces données sont accessibles à quiconque ayant accès aux logs et fournissent aux attaquants des données de reconnaissance.

✅ Conforme :

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;
}

Pourquoi c'est sûr : La journalisation structurée remplace console.log avec des pistes d'audit appropriées qui capturent les événements métier sans exposer les données utilisateur sensibles. Aucune instruction de débogage n'existe. La logique s'exécute de manière linéaire sans contournements conditionnels. Les journaux d'audit sont centralisés, contrôlés par l'accès et ne contiennent que le contexte nécessaire à la conformité et au débogage.

Conclusion

Le débogage de code en production n'est pas un problème mineur, c'est une faille de sécurité, un risque pour les performances et une charge de maintenance. Suivre les meilleures pratiques en matière de révision de code sécurisé permet de détecter ces problèmes avant qu'ils n'atteignent votre branche principale. Des règles automatisées de qualité du code devraient empêcher le code de débogage d'atteindre le contrôle de version, et encore moins la production. La clé est de disposer des outils adéquats pour détecter ces problèmes avant qu'ils ne soient fusionnés.