ルール
削除 デバッグ および 一時的な コード コミット前に コミットする前に
コード コード バイパス ロジックをバイパスするコード、 出力 デバッグ 情報を出力する、
または 停止 実行を停止 デバッグ デバッグ は おそらく
残されていた 残されていた可能性が高い うっかり 開発中に 開発中に誤って残ってしまう可能性があります。
対応言語 45+はじめに
デバッグコード、 console.log() ステートメント、コメントアウトされたロジック、ハードコードされたテスト値、または デバッガ ブレークポイントは、多くのチームが認めているよりも頻繁に本番環境に出荷される。これらの成果物は、アプリケーションの内部状態を暴露し、パフォーマンスのオーバーヘッドを発生させ、攻撃者にコードベースのどの部分が開発中に問題があったかを知らせます。トラブルシューティングのための一時的なコードとして始まったものが、デプロイ前に削除されなければ、恒久的なセキュリティリスクになります。
なぜそれが重要なのか
セキュリティーへの影響： 本番稼動中のデバッグ・コードには、ユーザー認証情報、APIキー、個人情報など、本番稼動ログに記録されるべきでない機密データが記録されることがよくある。
A console.log(ユーザー) 文は、セッション・トークンを含むユーザ・オブジェクト全体を、サポート・スタッフやログ集計ツール がアクセス可能なブラウザ・コンソールやサーバ・ログにダンプするかもしれません。これは、自動コードレビューツールが捕捉する、最も一般的なコードセキュリティ脆弱性の一つです。
パフォーマンスへの影響：過度のコンソール・ロギングはI/Oボトルネックを引き起こす。リクエストのペイロードをロギングする高トラフィックのエンドポイントは、リクエストごとに15-30msのレスポンスタイムを低下させ、ログのストレージコストを肥大化させます。Node.jsの本番環境におけるロギングのパフォーマンスへの影響は、規模が大きくなると急速に増大します。
コードの保守性： のような一時的なコードのコミット if (true) return； または
// TODO: fix later ビジネス・ロジックを迂回し、将来のメンテナンス担当者を混乱させる。これらは、文書化された痕跡のない技術的負債である。
攻撃対象の拡大：デバッガステートメントと冗長なエラーロギングにより、スタックトレース、ファイルパス、依存バージョン、内部ロジックフローが明らかになり、標的型攻撃時の偵察に役立つ情報が得られます。
コード例
非準拠：
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;
}
なぜこれが安全でないのか：コンソール・ステートメントは、PII（個人を特定できる情報）と認証トークンをプロダクション・ログに記録します。コメントされたデバッガは、実行パスを曖昧にします。これらのデータはすべて、ログにアクセスできる人なら誰でもアクセスでき、攻撃者に偵察データを提供します。
✅ 準拠：
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;
}なぜこれが安全なのか： 構造化されたロギング コンソールログ 機密性の高いユーザー・データを公開することなく、ビジネス・イベントを捕捉する適切な監査証跡を持つ。デバッグ文は存在しない。条件分岐のないリニアなロジックフロー。監査ログは一元化され、アクセス制御され、コンプライアンスとデバッグに必要なコンテキストのみが含まれます。
結論
本番環境でのデバッグコードは、ささいな問題ではなく、セキュリティの脆弱性、パフォーマンスの責任、メンテナンスの負担となります。セキュアなコードレビューのベストプラクティスに従うことは、これらの問題がメインブランチに到達する前にキャッチすることを意味します。自動化されたコード品質ルールによって、デバッグコードが本番環境はおろか、バージョン管理にも到達しないようにすべきである。重要なのは、これらの問題をマージする前にキャッチするための適切なツールを持つことだ。
.avif)
