Aikido Autofixプルリクエストから直接このページにアクセスされ、プルリクエストを完了する方法だけを知りたい場合は、‘実装方法’にスキップしてください。
JavaScriptエコシステムにはプロトタイプ汚染と呼ばれる問題があります。JavaScript/npmで構築しているSaaS企業の場合、依存関係で検出される既知の脆弱性（CVE）の通常20〜30%がプロトタイプ汚染によって引き起こされます。これらは通常、エクスプロイトは容易ではありませんが、最悪の場合、リモートコード実行の欠陥につながる可能性があります。つまり、これらを完全に無視することは困難です。
プロトタイプ汚染を防ぐ2つの方法
Node.jsには、`--frozen-intrinsics`というフラグの下でプロトタイプをデフォルトで凍結する実験的なサポートがあります。このフラグを有効にすると、すべてのプロトタイプ汚染攻撃を防ぐことができます。しかし、これは実験的な機能であり、フロントエンドのコードベースでは機能しないため、まだ推奨できません。これにより、フロントエンドとバックエンドで同じ保護を構築することができなくなります。
代替案として、プロトタイプ（およびその他のいくつかのエントリポイント）を凍結する14行のライブラリであるnopp（No Prototype Pollution）があります。
実装方法
1. ライブラリのインポート
noppをインストールしたら、アプリを起動するスクリプトに移動するだけです。そこで、他のすべてのライブラリをrequireした後に、そのライブラリをrequireします。以下のコミット例をご覧ください。
2. プロトタイプ操作に依存するライブラリのアプリ全体での安全チェック
他のライブラリを含めた後にプロトタイプを凍結する理由は、一部の他のライブラリがプロトタイプを変更することに依存して動作する可能性があるためです。他のライブラリを含めた後にプロトタイプを凍結するようにしても、アプリが再び動作するまでにリファクタリングが必要になる可能性があります。
例えば、Amazon独自のNode.js用aws-sdkは、「new AWS.S3(..)」のようなオブジェクトの構築中にプロトタイプに変更を加えます。このような場合、Node.jsプロセスが起動したときにオブジェクトが作成され、後のフェーズではないことを確認するために、以下に示すようにリファクタリングを行う必要があるかもしれません。
この変更後もアプリケーションが正常に動作することを確認するには、テストカバレッジが低い大規模なリポジトリの場合、より多くの時間投資が必要になる可能性があります。小規模なリポジトリであれば、今後プロトタイプ汚染に対処する必要がなくなるため、その価値は十分にあります。大規模なリポジトリの場合、より複雑になるかもしれませんが、長期的に見ればエンジニアリング投資は依然としてプラスのROIをもたらすでしょう。
