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) instruction pourrait vider un objet utilisateur entier, 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 de code review automatisés 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 code de débogage en production n'est pas un problème mineur, c'est une vulnérabilité de sécurité, une responsabilité de performance et un fardeau de maintenance. Suivre les meilleures pratiques de code review sécurisée signifie détecter ces problèmes avant qu'ils n'atteignent votre branche principale. Les règles automatisées de qualité de code devraient empêcher le code de débogage d'atteindre le contrôle de version, sans parler de la production. La clé est d'avoir les bons outils pour détecter ces problèmes avant qu'ils ne mergent.
