ベストプラクティス

推奨事項

• 自分のコードだけを難読化する

  ベンダースクリプト、ライブラリ、ポリフィルを VM 難読化しないでください。これらはすでにミニファイされており、難読化しても遅くなるだけです。

• comment モードで必要な箇所だけを保護する

  vmTargetFunctionsMode を 'comment' に設定し、すべてを保護するのではなく、機密性の高い関数だけに /* javascript-obfuscator:vm */ を付けます。特定の関数を対象にするを参照してください。

• 難読化後に十分にテストする

  難読化したコードは、必ず対象の実行環境でテストしてください。オプションによっては、コードが気づきにくい形で壊れることがあります。実行時の防御はテストの自動化ツールやデバッガーにも反応します。テストと CI を参照してください。

• 頻繁に実行される処理を VM 難読化から除外する

  アニメーションループ、リアルタイムレンダリング、頻繁に呼び出されるコードには vmExcludeFunctions を使用してください。これはルートレベルの関数名（Async Executor では最も外側の async 関数）にしか一致しません。ネストされた頻繁に実行されるコードを VM の対象外にするには、comment モードを使い、保護が必要な関数だけをマークしてください。

セキュリティに関する重要な注意

API キー、シークレット、認証情報は、難読化するとしても、フロントエンドの JavaScript コードに保存しないでください。

難読化はコードの理解や改変に必要な労力を増やしますが、暗号化ではなく、リバースエンジニアリングが不可能になることを保証するものでもありません。攻撃者が管理する環境では、ランタイムの動作は引き続き観察できるため、意志の固い攻撃者であれば、クライアントサイドのコードから必ずデータを抽出できます。秘密情報や、最終的な判断を下すセキュリティ上の処理はサーバーに置いてください。

実際には、次のようにします。

• シークレットはバックエンドサーバーに保存する
• 環境変数はサーバーサイドで使用する
• API 呼び出しをバックエンド経由でプロキシし、キーを隠す
• サーバーが発行する短命のトークンを使用する

何を保護すべきか

VM 難読化が最適なのは次のようなコードです。

• 独自のアルゴリズムとビジネスロジック
• ライセンス検証コード（クライアントサイドのチェック）
• 改ざん対策と整合性チェック
• ゲームロジックとチート対策の仕組み
• プレミアム機能の実装
• 料金計算のロジック

ビルドとリリース

難読化は、コンパイルとバンドルを済ませた出力に対して、ビルドの最後の工程として行ってください。ビルドパイプラインについては実行環境の互換性を参照してください。選んだプリセットのコストは、プリセットの選択で説明しているとおり、自分のコードで測定してください。機能テストはテスト用ビルドで実行し、その後、実際に配布する別のリリース成果物をテストと CI で説明しているとおりに検証してください。